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The Ada programming language has been available to software developers for several years, 
yet its acceptance into the real-time embedded applications for which it was developed‘, Ὁ. 
has been less than universal. Although many staff software engineers were quick to embrace 
the language ΒΓ they soon realized that the ability to assert control over the hardware was 
greatly restricted with the available Ada compiler implementations. The result was a 
disappointment, and often project delays were due specifically to the use of Ada on the 
project. Performance of initial compilers (and even many contemporary co:npilers) was far 
below that achievable from alternative languages. In the heat of battle” associated with 
hardware/software integration, sufficient time was not available to work out tlie vroblems 
with the compilers, and often cumbersome work-arounds were implemented. The iwpact of 
these initial costly experiences has served to retard the adoption of Ada for real-time 
embedded applications, although its use in other applications has exceeded most 


expectations. 


The Purpate of this project was to address the difficulties in real-time Ada programming 
from an “Ada technology” perspective, and to provide accurate details on some of the 
perceived problems with Ada. The project involves the development of a typical weapon 
system application with severe performance requirements. \The application is synthetic, but 
resembles many similar weapon systems. In some cases, simplifications were adopted 
because they did not alter the nature of the application sign{ficantly, and may have restricted 
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the ability to make the results of the project available. 


The approach used was to develop the software to be independent of the target architecture, 
and to increase the number of processors as necessary to achieve the required system 
performance. The unit of distribution supported was the Ada task. The project utilized a 
commercially available Ada compiler and supported the Ada semantics by extending the 
runtime system without modifying the vendor supplied runtime code. Initially, it was 
intended to use a “source code translation” method to achieve the distribution. This would 
translate the input source according to a configuration table and generate individual 
programs for loading on the target processors. This technique was not used because it was 
found to be somewhat easier to apply a -ink/edit step on the output of the compiler to 
achieve the desired effect. In general, it was felt that any production project should use a 
compiler that specifically supports the distribution of Ada programs. Full Ada semantics 
including the Ada rendezvous were preserved across the distributed system so that no source 
code changes were necessary to alter the allocation of tasks to processors. This allocation 
was done using a distribution table that specified the object names, the processor ID, and 


relevant characteristics. 


The project has identified areas in the Ada language definition that are vague and need 
special clarification with respect to distributed systems. Although some of these have been 
identified previously, no resolutions have been adopted and it is hoped that this work will 
shed some insights into how they may be resolved in future interpretations/revisions of the 
language. Furthermore, the results of the demonstration should help to indicate what is 
achievable using Ada, and how performance can be improved by judicious use of language 
features. Finally, the project deronstrates that it can be practical to use distributed systems 
effectively within the Ada model of concurrency and that the duiicuity of adding additional 


processors can be minimized. The work performed on this project will be available to other 


researchers and compiler writers to aid in understanding and resolving the real-time Ada 


issues. 


The project used the Ada tasking model exclusively to achieve concurrent execution. It was 
our objective to fully utilize the real-time features of Ada to meet performance objectives. 
Unfortunately, we found that while the latest compilers are starting to provide these 
fextures, they are still quite far from being error free. We spent close to ninety percent of 
Our integration time analyzing problems that were the result of runtime and code generator 
anomalies. If this had been other than a demonstration project, we certainly would have 
been forced to alter the design to limit the features used. Application developers should be 
prepared to spend additional time during integration to resolve such problems if they expect 


to use Ada as it was intended to be used for real-time systems. 


Mess WAVE UENO ΡΥ 1 
2. Demonstration: A pplication isscssceissscscossvatescasccasiceuscssarsacdesconeuchcabsvivessaayesasiekcbastascisehistersentursastivane 1 
2.1 CSR GIN INCE :-ς ssn istesessenessncsdscsvasesidattacsestasentsncsctuvicicadstedstpatcesesbaidebindiatoxcsbnivesedupeieoateats 2 

2.2 Ada Time Oriented Method (ATOM) ........ccssssssssssssssesssesneeseessessseasssesssesneensseneenssseteees 3 

Did POSER yas s esas sec ses canst huesoncedicreoscepsaccasesbioaa Rok aissciatebecs eee eases un nse awe 5 

2.4 Ῥτοϊοϊγρο 550} 65. 5 secs. ops ausescasaedeyesnaticpaisaascocosoiascasebigedussnenshar sada iaeracaalabenseaseatoruneake ree δ 

2.41 ΟΥ̓́ΡΕΟΣ sasccashakdases ας δ cos ουρννρνς, ἐεοοςς ἐας, ρορυτς, νυ, ἐςς νρ οὐρ ρους νορξ  καλρ θυ ευς τς  οτξο ον το εν 7 

242 Comimunica ΠΝ Driver ιν οι ἐς οςοςςοοςςοςυρ νος φουεν ρους ορο οὐ ςους, τοὺ ροτς ἐρξυνονουνς ἐντὸς 8 

DAS FROCKEE CG τις ΠΡ ΠΡ 8 

2.4.4 Operator Interface oe ἌΡ ΡΝ 9 

3, Compiler and Language Problems Eucountered ..............csccssscsssscsssassessssecsanescseosenensesseeecace {2 
4, Hardware Problems Encountered ou... ...cecccs.sscssscssossssssecsesosssaveeesesaeessneeessoeener ice Padded sientes 16 
Ds DISA ented A ΤΡ ΠΡ tceses scacyatann ccd cossc acs ica casaaadei ueadaessaastacgaenesestaasaesasvateaeataodaeereneas 18 
5.1 Θεδπηϊ οι οὗ Termin socoe bic. cieics cssscssatcoasaccsacesenscestycestateseeaceuautosasccadvancetsoasusasansestepiosecasacten 18 

52 Project ODOC VES cscs siaicincisscassasdacaccenssscatascaseuiustbisosiebad adoeosbbeosiassuckaccgsetobadseasbedasvadeossbols 19 

D2.) URI OF Distrib uta ΡΒ 22 

6. Distribution Implementation Details .................sscsssscecssssscssssscasscstsecesnescerecesacscssossessessecssoterees 23 
91} 2. ECU ESS UC seo sca succes anatase Saou cetsscascnhes ΡΝ 24 
7.1 RANGA BON SSWOS .....:....(ἱουονοορυνουροιοονορος ον νου οουνοοουνοος σοφοούοοο ρος ἐεοσουςοδορονοσυςο οὐδοῦ ῥοννοοκορεύδεουροὶ 24 

7.2 Issues Addressed By the Demonstration Project ................sccsssscssscsesseceseresssesacsoneeeses 28 

Fe MPOLELBOR ἢ ΕΟ ΤΡ 29 

7.4 Ατομί(οοῖυγο ΘΌΡΡΟΓΙ scceciniccsensvenascvsicscaiass ceossnnecssesoscsussezedescsdcacesticbosasesdeussnsnspciassaisasevvaese 29 

8. ΤΙ ΠΡ ἈΠΑΙΥ Ξ π᾿": νους τος, ρους ρους ορροιυςςθς ςςςος cate has ἐλοςρυ ον ϑοςο ἐρςρρο ουοθυ ts acetate leu cersec cats 32 
9: Principle Εἰπαϊσθ :..}........00ονοουυ οὐ ον νου νυυν ρους ον ροφερουνουςουοφυροοὺς οὐ φονοβ ρος κοςο οουοουςοιςοςονοκονοῶς ον esscesines 36 


Table of Contents 


Zio 


Table of Contents 


10: ΘΌΪΙΠΊΒΕΥ. τιον ρευο theses cece aes ocr cea ak ss vack cu caesveatcduncs ov nev cada n eves toad ease aes aabeicies cs εξ τς ῦοον 38 
LNs. ROTERCHCOS oases Seemed 40 
12. Appendix A - Specification for the Border Defense System .................sssssssssssssessesessscsesssees 41 
12.1 VOR VI CW - :ιιοοιννουνςι ρορουςς ὀρ ςουζοςουρος ἐορςοοςςνθςφουὶ ροῦν δου ες ος νος ὀφούθνςβους ες θςςουφοςοοφον eae 41 
12:2 FROCUIIECIINGIIES es 55s cncscrcasccssenasvasveveusadossspscasceecaoupst vatuaedscasdoagosiactataasoteceldesaisceaseasatdentataaners 41 
ΑΝ τ 4 8 DIS ΕΠ ΤΠ 41 
12.2.2) Operator Commands .Ψ.:.....ὅὁκ..ος ἀουυυυν ρους, ρρυνυουν εν ουρο ρου ρου ουνονος ὀροοροοςἐρνοςνο ρον 41 
122-5: ROCK CU COMMON Τ ΤΥ ΡΡΡ 42 
12.2.3.1 Encryption (Phase: Π). ccc ssacsscpscssopcscsscchecausscinssveanssustsvasspsdeeriaeeasevandt 42 
12.2.3. ROCKCE ἘΘΡΟΓΙΝ... οι τ ουρκοο ον ρους ορονονον οι hsccaccbaceceastestne steel caesinzesed 42 
12253-Rocket Οὐἱἀάποδο, ρος οὀουυνς ρος νου, ον νυν ουτονος ρος μουν ς ννοονονόλις 42 
12.2.4. Bottle Stains isi sas sccssscas sadespcoxuces δου οὶ ουνουουυς ὀρρουυούυοξορ ρου ύρςνος νὸν κου ἐς ες ταν νοῦςνο νους κοῦ 42 
12.3 Performance Requirements .............s.sccscccssssssssssscesssosacesecssesessnscesessacacacsseceseccscacseasecees 42 
12.4 Quality Assurance Requirements .............ccssssscscscosesesescssscsceceserssesececesesesesecesssesessesees 43 
13. Appendix B - Parameter Data Base ..............scsssssscscscssesssesseseseserecesosscsnassesscesensecasesoresecseseseees 44 
14. Appendix C - Sensor Interface Design Document ................sscssssssssssscorssessesecsecaresseserescoeaces 48 
PAT PUES τιον οι vansasabvcsossaastvle coiwsviassasegssdedesesies avsasiesstercucnsovsonlessshasieccaseaqavincvyuaccntiene 48 
142 ἘΟΙοΓΘπΟθθ᾽ 5.1. sci soses cass basa ρυνιυ ρυο οι ςς ο ρος ςορο ἰοτονυ ςι ρου ρου ρου ρε φς νου οδος βοῶ, δεῤ ούξεὐαννον, anne 48 
14.3 δα υ ΟΠ ἢ Ἶδ᾽ ..ὕ..2....ὡἰθἐουςυ ρους οςςου νος οἰ υςυνυ ἐς οἰκο ὀρ ύρος ἐς ἐοθου, ρος ρος ςςξυνςο ένοϑορ συ ροος ἐξ ςοόςο δο 48 
WAST το τολ 6. ον ΠΝ 48 
14.3.2 ΕΥΤοῦ ΝΑΘΟΟΥΘΥ͂Ν Saiceccsssetaazciveisnsccoalscvseksoassusnsssbansqnceidedh cons tbbestcieacsscesnseessiweacaiveasee 48 
14.3.3 Network Address ASSignment .....sccccsccsscsssssscessssessescnsseresnessesonssnssosernscnsereess 48 
14.3.4 ΝΟΥ FORMAL siceilessosipseteastteccetaiesactscehieieaas cael aeaeuctboechalussaaansgusananvioesieneares 48 
14.3.5 Message ΘυΠΙΠΊΔΙΝ sista cisiscssccossesescssostashccoilcnsisabbchdcecastasoatasnlentasbeseatoantnchesinteies 49 
14.3.6 Message Descriptions ............cscrcssssescsosenessesnsesesesessscconenssussseseeessssesecesesesesessos 49 
14.3.6.1 Target_List Message ......c.-cccssczsssscsssesssesensoesucceverneenersssnessncanssorensenses 49 
-ii- 


στ --κ εΘἁΕὩ σ’  -ς-. ἰ--ΦΦ«Ψ «........1ς1Ὼῃ᾽.᾿᾽.ΘΔὍΧὍΧὍ2ὕὃ00.5΄ΧΆΧΆ.ΧὉὋᾳὉᾳ'..............νὉ cit ed τ τ τ 


Table of Contents 


14.3.6.2 Destination Addr€SS ssessssensssssssnssnessenssssnsisetestnssntseesssnesesee 50 

14.3.63 SOUSCE AGGIES asic sacsiese ουνορυν ted yasacstueseatesyassessanssastsananacbersuangeensnasiaace 50 

14.3.6.4 MESSAGE TY D6 oS cchcsiicscgsstasasecacestcccaaciveseasssabicnearcs tascseantods Gouativis 50 

14.3.6.5. MeSsace: ΓΟΠΡΊΠ 0. οι cesisssusecssctesnssseniepassanwiocnarsnsaasssanaicoiienaies .51 

14.3:6.6 Vie Vag sa ει ον ες οῦνιςυ δος δ νος ρος ρςςοι ρους ουξο ἐρφουνος τος οουνος κου νυ οοτοις 51 

ἘΚ SO AEC ΦΉΣ 51 

14.3.68 Number Of ΤΑΣΡΟ δ... νου νυ ἐρου ρους ὀρρος ρρρυροςνος ρουνο ρους ον οϑονοροκουύν ει ον 51 

14.3.6.9 Target Report) ....ρρριρονοονοουνουοοοονοσοουοοσοοσοδοοο σου οοοοοοοοσοοονονοοονανοοοοσονον 51 

14.3.7 Time SyACHronize/ Initialize νος, 51 
14.3.7.1 Destination AdGress. νος 52 
14.3.7.2 SOURCE: AGIOS. .......οοουυυς sessasanqtosdssciaaaciecaysnesedstostotaniaesocensteshalbetoies 2 

14.3.7.3 Message Type .....secssssccssesesseee eosonssesconseessonsessonssencunesoesenecsousesesonvesecuesess 52 

14.3.7.4 Message Length ..........cccscsssseersecseseecececerecsesess τ ese ss 52 

BASS ἜΠΡΑΓΘ νυν, Mascsmsieise ἐς ἐδ ορωροιρος ἘΉΕ Uisiententedates ἀρ νονδα  ρονῖανς 52 

14.:3.7:6. ἘΠῚ FAG ssscntass ὀρνυρ να pavenssiatconsochadesmesasnsacesedssachextidualacouteigsuaneditcandeoaiay 52 

15. Appendix D - Rocket Data Link Interface Design Document ..............ccscscsscssscsssesessssseeees 53 
1 ΡΟ ρΟϑδι ἐν ἐν ἀν Ses Rrra ον νυν ton PPR Po rR RR TE Rar 53 
ES.2 ROIGROM CES: oats usshacacenscassescpsasacentasatecastocoush ceeussseanscseaxckssajostouteyelias duccatencruaiieleseaseiteuamonite 53 
15:3 Βοῆυϊι INC INE Sic coc ik cscs ὦ dasa aad cee caso νον μουν τον ρρςο  οῦνς ἐς absiptcdouniocseseakcners 53 
15.3.1 ΡῬγοίοοοὶ Transmissions: isscsssciedeavessctessestusatiseicstadensattanesciuosasnstateasetecdcoesieeasslan 53 
PDB i2 τὶν () 4. πο οΕΕ ΡΥ ΠΡ 53 
15.3.3 Network Address Assignment .......ssscsssssssssssscsecsssscessessesensssssossnssncensceceaeeons 53 
15.3:4 Wot FOr scscccscsstcucacesscustanssseavicasndsnsusasasstaaseSssatasssecvanncesbscovdeopsstontninsdicietegs 53 

UD 3 5 Message Summary asicsccsscutssssscscsncsseuisteaoiassacdebubesnscoastanteasseatenssotedessacaouses teedes 54 
15.3.6: Message Descriptions: ssicjussssssvccisccuctscesssessavens sateen ieszussatecasosiuesuatdinsgealesnsedeiusee 54 
15.3.6.1 Rocket_Report_List .........ccssscsssscssescsssesnscensecsnessnnsesnscensccensesoesessneeses 54 


Table of Contents 


15.3.6.2 Destination Address: i, scsssissctccassssteiecntecesiasesbnnesesseenanonecteoves iossspesetivsrs .55 

15:3:6.3 SOURCE Ααἀαγδϑ © ci cescssssessscctovapoasccssssccasasirccccesnyscsersnusobpseansaagrstvantentenens 55 

15.3:6:4. MeSSave: Type seaccaisssics υυυκουῖου νου ες ννο νου μους ουρυυουυ νυν ως ρους νροορορυνονεῦο νοῦς 59 

15.3:6.5 Message ΠΡΊΝ ον ρος ον υρουυυς, ρους ονοιο νους ρου νου ρο ροθοςυ νοοῦν νρ κἰρς θυ σος 55 

15.3.6:6 SP Are 1... ρνολρυυουυυυυς  ριροουυοςυ οι υς νυ μου ρον ους κὀνουυνον ἐς ονουυούρςτουνοῦικεουυνόρρος .55 

15.3.6.7 Number οὗ ROCK CtS ......μμρνννρνροννννονρνν νον ον οονν νον νονεοοονοννοοννννοννοννσονον 55 

15.3.68 Rocket - Report) cists cssstesshcsuencicasseattidessttagoabossenivcnnteasnesaivateotetion 56 

15.3.7 Βοοκεῖ Guidance LASt  s.cpsaceasss.visscccisuchsnces aeapesiinnnticvensenasonssnassaboevecassboigescosstves 56 
15.3.7.1 ϑεσπαῦοη AG dress foi ssscescrscccaveenstcencrseasectsice cotacdncsocecicensiestcterbaase 57 

15.3.7.:2 SOUrCE Adress ,........ιοουυςυἰουρορνερονου ρους ρος οθος ecescccatetsle iesepasarssccingse 57 

15.3.7.3 Μδεβᾶρδ ΤΥΡδ .5:οννοςυος ρους ορυυςυς νος οςνυ νους, υνρεγειουυυ νυ εο ον ρλυδοιουθρούρος 57 

15.3.7 A Message Leni gt scsi. ccssccsascsoucsssescssoeatcnspetindséstsovaststepsubosbaveioatsagescecsnncs 57 

15.3:7:5 ϑρᾶζθῥιι assis sassbecasecssczssuseasagncdges φορυςφανους οὐνολ ερυς ουθον κε υκο οςυροονεξουςο κενοὶ ες ρει 57 

15.3.7.6 Number of Rockets ΠΝ L Siedewaumianasncnumite 57 

15.3.7.7 ROCKEt ὈΙΓΘΟΙΟΠΑΝῈ sei cosccccssnstce eaves ουνοοροῤι ον, ἐενοουι ορουουςρυ εὐ ουκεοκολοῦονς 57 

15.3.8 Time Synchromize/ Initialize sccsscccsccesssesdesasessssceonocconsesescvsdavisasanedsescssaoioansocoreta 58 
15.3.8.1 Destination: Address \sicccisiecsisscssasscackesssninscdadseisceseonstasncasnvsiniugsaarsecacnd 58 

15.3.3:2 ϑούτοδ Αὐαγθϑβι: του ccadaccescosssetndusatsnigessestncestsvcicauesMdeinaibatinsstaniaius .58 

15.3:8:.3. ΜΜόοξάβο Type soa sicccesccscadascasetscicaicosteecsaneticwsssacccdaccsaguthiatvetonicahortuseeese 58 

15.3.8:4 Messase Lengthy. sisseissscosnitesccussensasssscsaseesavebabsicsestospunssanesusseasenatanaloutne 58 

15.3:8.5 ΘρΆΓΘ᾽. 1. ch eccsscas dacs cakes pases sncdeasebaontcasyncadasienss hotangem nvnumnnstioess 59 

15.3.8.6 Time Tae τιν. cascsisasstalsscecd ndsiscacehnanssssssavecewanvaucvesrusosececuttsohen ορις ὀκὀολένοις 59 

16. Appendix E - Specification for the BDS Test Simulator ..............cccccsesscserssssssssevscnessesenenes 60 
NGL SCO 00 iscsi ech css cescickcecevecls issue seadenscansdlocacskdcavedencsesnaacavecansats insaa ce dabcas@tpststteateeaucieanctatatalseete 60 
16.2 Applicable Documents ..:..:...:-ssscecscscoscoorscasesssasscessacssssesstsvascsossvaceessatecseanesanveccenseeseoresses 60 
16.3: Εδαὺυ τ OMICS S isc. scscci ccc checcsickadeataceeh nig deaincebntaes aceasta heaped ed caesi ἐδ ρὀροξ ουθ φόρος 60 


Table of Contents 
16.3.1 Sensor Simulation ........ : πα σον 60 
16.3.1.1 Target Data in Parameter Data Base .............0. poe eka 60 
16.3.1.1.1 MAXIMUM_TARGETS. .......ssssssssssssseessvessscenecsnssensenseesses 60 
16.3.1.1.2 TARGET_CREATE INTERVAL ......ccccssscsssssssessseessees 60 
16.3.1.1.3 TARGET CHARACTERISTICS ..........sccsssscsssssesseesesses 60 
16.3.1.1.3.1 MAXIMUM _VELOCITY ......cecssssssssssssssessesssneense 60 
16.3.1.1.3.2 AVERAGE _ VELOCITY 0... cessessssssnsesssesssenneceee 61 
16.3.1.1.3.3 VELOCTIY_CHANGE_INTERVAL .........000 61 
16.3.1.1.3.4 MAXIMUM_TURN_RATE .....cessssssessseesesseeeees 61 
16.3.1.1.3.5 TURN INTERVAL sssssscccsiscssnsscansssssecssass tantensccens 61 
16.3.1.1.3.6 MAX_TURN_ANGLE .......ccccsssssssssscnseesesenesenseente 61 
16.3.1.1.3.7 VUNERABILITY RADIUS .....eeescecesssseseesseennes 61 
16.3.1.1.4 TARGET REPORT INTERVAL, ....eccscsssesseeessenteees 61 
16.3.1.2 Target Creation ............0 πΠι πσ Ades Deities Pactiaancs 61 
16.3.1.3: Ταρσοῦ MOTION | sssccecscsccatecsssceccevctuichsnct desasedolahecunscsenedenasgnadedetanigabiansedsee 61 
16.3.1.4 Var Get IR EDOTMS oss asnssccsscsvacssicsssiatasetsavcsesbccsanticcdsascuadnsantevdedatcvanstysnesen’ 62 
16.3.2 ROCKSt Simulation ajocsescsucscscinccsscdusieosssennosssanesesasiasesciecanseuseniiotasediessassen de ceteclious 62 
16.3.2.1 Rocket Guidance .......0+. s.cssccrccssssaccossssoneatsursorscceseesasstnsensstensesiecnenssenses 62 
16.35.22 ROCKEt REPOrt [515 cis ccicscssissciscsssencastvensandcticiesss sucess ceaieseistonetioaastantes 62 
16.3.2.3 ROCKkEt Fe rrmimationy sssiisiiecsisisssccccensssstasocstadsAsecactasentsvasryasbbedsoiosroasves 62 
16.3.2.4 Rocket Data in Parameter Data Base ........sscccssssssssesssessssesecsesees 62 
16.3.2.4.1 MAXIMUM _ROCKETS. .......cesssssssssssssesenserssenscnnsensesneessees 62 
16.3.2.4.2 ROCKET_CHARACTERISTICS .......ecsssssesssssnssesenceesees 63 
16.3.2.4.2.1 ROCKET _MASS. .......cescsssssscsseessenecessensensessssoesencers 63 
16.3.2.4.2.2 ROCKET FUEL ....ssscssssovscsssssnsesnsesnssnssssnsconssssceens 63 
16.3.2.4.2.3 ROCKET THRUST. ....cssscssosssesenscrscensensessserseensess 63 

“ve 


Table of Contents 
16.3.2.4.2.4 BURN RATE aise scccichsncssatcinssnsasectoyssuonesssusesigiosee 63 
16.3.2.4.2.5 TURN_BURN_RATE .......csssssssssssssssssssessseseseeenees 63 
16.3.2.4.2.6 FORWARD DRAG. .....sesssssssssssssssssssserseseseessesseee 63 
16.3.2.4.2.7 SIDE: DRAG: ssicsisiccussdesscissecssicasececeusicvenerisneesnaeecdesd 63 
16.3.2.4.2.8 DRIED ccsscscstessceinleeliliotionetee ΠΡ 63 
16.3.2.4.2.9 ΚΟΟΚΕΤ ΤΌΕΝ ΒΑΤΕ ....esccsssssssssssssesesessseeee 63. 
16.3.2.4.2.10 Launch Data ic. sscsessssccasvssscesesedesescesesassonstcosisenstaniee 63 
16.325 ROCKEt MOUON οι ciate wcadeaceanteedtyoaasiel acs ature 64 
16.3.3 Parameter Data Base On-Line Update μονα 64 
16.3.4 Scenario Goeneration/Playback .....ccssssscsscssssssscersssssoransessersesssnsesesessscssesoeonses 64 
16.3.5 Time SyAChromizaty OM acccgisescesscecvevanscscecesseiastesndeascseenucsiadbaratesssssaenonbecaastadcevaen 64 
16.3.5.1 SenmsOr Subsystem cscsssacisisscscisecasonssatcsces yaasiasenacmedesantiseenacstaecaacseicnse 64 
16:3:5.2 ROCKCE Data: LiKe ps ssictcnccssnacsn, close asisassscuiest quien rear lascsae se οι 64 
16.3:6 Operator Inter a ce sissss λους ΛΑ sad esas kaa ara δου ρος and ρέν ονες δ, νορορος 65 
16:3.6.1 Operator Display ye icsivsscscen sects: sistacacuvcertcaitadetctepiveceonsteaassicrcgacutsscunns 65 
16.3.6.2. Operator Un pints iiss, Wascckatin haccsserstaaiososbecsunvcs ccsueseaceeaiosananenwloenss 65 
16.3.6.3 Parameter Data Base Variables ............ssssssessscssssssssessssessssecscesensees 65 
EGS: 7 vai Ent Vest ceca eccicvvdek osssaatecccsatecconessocbuans lass lacspseawecesaateosivanann vonsauatyeooionaed 65 
16.4 Quality Assurance Requirements .............scsssecccsssssecssesssssssrsasessnsessencecneacoscsstossseseseaess 65 
16.4.1 ϑοΐμδναγε DOVelODTG ME ac cssssacetasie acta goesseciadasscascedecdesusipsssitsciaesndvennaeseceecdeal 65 
16:42 Test Proce Gres ΠΡ 66 
"ΤΟΣ SD RELOE BU DEUS cscs οτος 66 
16.4.4 Programming Language .............coccsssccssssesesssscssssseseesesnssnsescotessnsersessssnsessesseses 66 
16.4.5 Implementation Dependent Featuress ..............c.ssscssscscsssesssesssesessesnsssesesesees 66 
17. Appendix F - Ada Style Guide ...............sccscsscssscsssssessesncsssssessecssesscsosevecsnensnsssssssassesecesseseseseeses 67 
17. Ταϊτοαυδεῖσα assists sass spe tase daasacanosbembs beste cesousintan ths dedusnecesansecietuapeinssieinie 67 


-vi- 


Table of Contents 


17.2 Identifiers ..0........ccccssscsssscecsceceee : Ἐπ ΤΠ Το 67 
17.3 Identification, Alignment, & Spacing ..........csccccscsscsssssessesssessssssserecessrssere: sesasseesecees 67 
174. COMMEONES sates secsets ses ceatskan ath caitecacd eae εὐορονονονοου ν υςφου, ἐἐ τος οὐτου ον υς νϑν ρον οι οῦτς οτος νι 68 
17,5-PDL ΒΕ Θ΄ ἘΠ ΠΈΡΈΡΈΡΉΉΡΒΡΡΡΡ 69 
17:6 Ἐ ΘΓ ΕἸ INS «554 5.2-2cs5d.sss tee stdexsnaseaicey dsteol vaceas wanes ene udvearsabacaaerasisiaea esau autos 69 
17.7 Naming COmyentigys sciosgcccceclecessccsdscectees: ncocceancleniaiaGaeniarintnntlGnaneabia 71 
18. Appendix G - Sample Timing Budget ....0............cccccecssssssscecersssscsceseseenesseeee: Aiacrieaatartuee 72 
19. Appendix H - Border Defense System Ada Source Code ............ccccsccssssssessessssssesesssserseoese 75 
20. Appendix I - Distributed Runtime Source Code .0..........cccscecsssssssssseees-ccoestenssssaceeacsteevereses 179 
21. Appendix J - Key Control for the Border Defense Systeiin ..............cccccssssscccesseeeseesersecseees 237 
DI ASP UME WO SO coset 0sice tus νουςί θους conceal caseun tstseussaashahoancdaucauseuuth dese aitats ἐκενένεδοῦ, ἀπὸ δε ελεόνε λιν άξοϑνς 237 
21.2 ΒΑΘ Δ οὗ φ. saisstistsr atopic hnandionuiceonachenttnaneaatinnidacanii at 237 
21.3 Key Μδαηδροιηθης........(οονονννονονονονονονυοονουνουοοσευνουνονοοσοσονοονουσοσονυνονονοννσοοοοσνοσυννοοονσονοοννοσονον 237 


-vii- 


List of Figures 


Figure. BDS Top Level: Design asi scciiy cio. (ocsccystsessssessecsdecsudensiesveavancayoveeateanssucastansesssseyeearUeatnsaxedeos 11 
Figure 2. Available Time Prior to 100ms Deadline for Rocket.Control .............:cscccscsssrseessees 35 
Figure:3. Rem@ez vos Wisin gs: gs iocccscocscsccescsascsccsosercecectces scccvskenasteactctuscecethasspandedvaxteonspacosaseriansiecrnse 35 


viii- 


Demonstration Project Final Report 


1. intruduciion 


This paper is divided into two separate, but related topics. The first topic covers the details 
of the application chosen for the demonstration. Since the application was developed with 
the intention of running on a single CPU, it is essentially divorced from the underlying 
implementation hardware architecture. The second topic is on the distribution of Ada 
programs for loosely coupled multiprocessors. This aspect of the project has been an area of 
considerable debate which is unlikely to subside until several implementations resolve the 
issues. Unlike tightly coupled processors, loosely coupled processors incur significant 
oveiiead in inter-processor communication. For this reason, it has been questionable 
whether or not the tasking semantics of Ada can be (or should be) implemented for use on 
real-time systems. This section discusses many of the critical issues in using the Ada model 
of concuirency across a network and provides ihe implementation st: 1icgy used on the 


demonstration project. 
2. Demonstration Application 
The deiuoustration application was chosen among three proposed candidates. 


1) Attitude/ Altitude Control for remote controlled helicopter (RPV) 
2; Vision-based sentry system to perform guard duty 


3) A weapon system to intercept attacking armor 


Lhe first candidate was rejected because the risk associated with the mechanics of the 
system affecting the success of the project was deemed to be unacceptable. The third 
candidate was selected over the second candidate because it seemed to have greater 


similarity to a majority of DoD applications, and because of more severe real-time 
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requirements. The selected system was titled the "Border Defense System (BDS)” and is 


designed to provide short to medium range protection against a massive armored attack. 


The complete requirements for the BDS are contained in Appendix A, however the main 
characteristics are summarized below: 
- Hard Deadline Driven application: failure to meet timing requirements will result in 
total mission failure. 
- "Processor in the Loop" flight control with dynamic target tracking. 
- Complex problem, with interaction among several different functional areas: 
Message Reception (from Sensor Interface and Airborne Rockets) 
Target Tracking and Prediction (up to 100 simultaneous targets) 


Rocket Tracking and Guidance (up to 20 simultaneous rockets, rockets travel at 
supersonic velocities and are guided by updates every 1 ) 


Real-Time Graphics Updates 
Real-Time Operator Interface (Mouse peak data rate of S00HZz) 


Message Transmission (to Rockets and Rocket Launcher) 


- Using current technology: 32-bit Microprocessors (80386-16MHz) 
- A separate program was designated for the simulator initially, however the 
simulation portion of the project was incorporated into the system as additional tasks 
and placed on a separate processor using the distribution technique. 
- Less than 1.0% "code" statements. No assembly language allowed. 


- All application concurrency is expressed using the Ada Tasking Model (Rendezvous) 
exclusively. 


- The program consists of approximately 3200 Ada LOC, of which 26 are Inlined code 
statements. It is divided into 31 library units or subunits, and contains 12 tasks (1 
interrupt entry). 


2.1 Design Method 


ΕΝ 
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The selected design approach uses an iterative technique to refine the system and software 


design. it is Time/Risk Driven to address the areas that are perceived most difficult first. 


A key component of the method is to prototype those algorithms that are known to be 
required in the system, yet their execution time is difficult to accurately estimate. The 
resulting prototype data is used to develop tiining budgets and design a software structure to 
insure correct timing. Emphasis is placed on meeting (software) deadlines first, and to get 
the exact functionality later. (However functionality must be sufficiently correct to model 
the timing accurately.) This approach is driven by the (unpleasant) experience that it is often 
much easier to "fix" the functionality than the performance. Put another way, it can be 
extremely difficult to improve the performance of a system that is grossly out of 
specification. Systems that are initially 5 to 20 times too slow are not uncommon, anc 
frequently result in complete redesign. This places timing on too of the RISK list. Where 
ihe functionality uf some processing is ποὶ well understood, these are also appropriate areas 
to prototype. Prototypes may be utilized in the final product providing that they are 
upgraded to insure compliance with coding styles. The process associated with the dcsign 


method used is described as the Ada Time Oriented Method (ATOM). 


It should be noted that one possible drawback of any iterative technique is the confusion 
that can occur in the minds of the designers/implementers with the different variations on 
the design. Care must be taken not to "brainstorm" at the implementation level for fear of 
mass confusion resulting. The degree to which a clear state of the system design can be 
conveyed (either graphically or textually) dictates the freedom with which designs may 
evolve. To ignore the nature of humans to confuse very similar designs by getting details 


trausposed in their minds, is a prescriptiou for long integration cycles. 


2.2 Ada Time Oriented Method (ATOM) 
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This software design technique is targeted for hard real-time embedded applications, where 
the most difficult aspect of the project is meeting the timing requirements. In these 
applications, the correct functioning of the system depends on proper timing as much as the 
correctness of the calculations. This method may not be appropriate for applications that do 


not have a significant real-time component. 


For the following steps in the method, the term "message" simply refers to an I/O 
transaction of any type. It may be a single byte, or a complex transfer of data items. — 

Sep 1; List the modes in which the system operates that result in different flow control 
and/or timing requirements. 


Step 2: For each mode, determine all input/output requirements of the system. List all 
messages with their sizes, average, typical, and worst case periods. ὔ 


Step 3: List the events that have special timing relationships. Generate a chart of events 
showing their relationships (Event Timing Relationships - ETR). 


Step 4: For each message, indicate what event invokes generation of the message. 


Step 5: Develop a test plan to detect and record events that meet the system requirements. 
(Thinking about how to test the software is an essential part of the design). 


Step 6: For each message, indicate what function(s) is(are) required to process it. 


Step 7: List all a aged related messages together. These are messages that can be 
processed sequentially without intervening delays. Distinguish between those that can be 
processed sequentially from those that must be processed sequentially. 


Step 8: Allocate the processing of messages to tasks according to message priority and 
temporal relationship. Pay special attention to deadlines. 


Step 9: Assign priorities to tasks, dictated by the priority of the messages in the task. 
Highest priority tasks will typically be associated with hardware interrupts. Insure that the 
hardware supports the interrupt priorities dictated by the design. 


Step 10: Produce high level PDL indicating the functions called. Use packages to combine 
logically related objects and to provide isolation from those that are Ἐπὶ ipo se functional 
decomposition to provide additional detail. Provide the greatest detail for those areas that 
are most likely to impact the performance of the system. 


Step 11: Develop threads based on the individual paths within each task. 
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Step 12: Document assertions made in order to anes the required timing. For 
example: “High Priority Task A will only preempt Task B once per 20ms, and for a time less 
peli in length.” Maintain a data base of all assertions that are related to external 
interfaces. 


Step 13: Produce static timing budget of each path segment, using "best estimates”. Build a 
model based on threads and timing data to compute processor utilization. 


Step 14: For execution time estimates that are uncertain, order them in teims of greatest 
risk. 


Step 15: Starting at the top of the UNCERTAIN list, prototype each segment to determine 
actual time of execution. 


Step 16: Feed actual times back into the timing budget and recalculate processor utilization 
with the model. 


Step 17: Model event activity and compare against requirements. 

Step 18: Develop a worst-case (or several worst-case) scenarios that can be used to test the 
system for meeting the difficult timing requirements. These should be used to convey the 
scope of the real-time concerns to the individuals writing th:: software code. 

As new I/O and Events are added to the system (hecause of mid-cuurse design changes or 
because of previous oversight), iterate on the above steps to mainiain processcr utilization 
and response time metrics. Using this information, intelligent decisions can be ade 
regarding the efficiency of code required. The process steps above should be automated to 


the greatest extent possibl: so as to facilitate design changes, and to allow exploration of 


alternatives. A sample timing budget is shown in Appendix G. 


The general philosophy should be to always have a spectrum of choices to select from that 
pruvide increasing performance, at the sacrifice of memory, complexity, and ease of 
maintenance. By knowing the difficulty of the real-time aspect, the program can be written 
to maximize maintainability while still meeting the performance objectives. A program that 
is maintainable but does not function because of performance problems is just as useless as a 


program that functions but is not maintainable. Both objectives are essential. 


23 Testing 
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The design should incorporate testability as an essential requirement. It should be assumed 
that if the system can not be tested, then it does not work. Furthermore, mechanisms must 
be provided to allow logging of software faults whenever this is feasible. Experience has 
shown that real-time systems frequently fail under actual conditions, when they did not fail 
under nearly identical conditions in the lab. This necessitates being able to provide some 
useful system-state information at the point of failure so that some insight is provided to the 


maintenance engineers. 


Testing should ve done in a way that makes automatic regression testing possible. That is, 
command files should be established for the testing of each CSC (Computer Software 
Component) down to the unit level such that the suite of tests can be run in a fully automatic 
mode. Command files on the development host will place the simulator system into a 
predefined state, initiate the executable image on the target and collect the results of the 
test. When necessary, breakpoints may be set using command files for the debugger. Source 
lines that will require a breakpoint should have a test point comment: "--TPxxax" where xxx 
is a 4-digit decimal number identifying a unique test point. The automatic test procedures 
(command files) should reference test point numbers, and will be machine-translated to line 
numbers by a TEST_POINTS tool. At a minimum, each testable requirement specified in 
‘the Software Detailed Design Document (SDDD) should be verified in a test. Additional 


tests should be written as necessary to improve the reliability of the software. 
2.4 Prototype Issues 


During the development of the prototypes, several problems were encountered that required 


design decisions. The critical areas that required prototyping were enumerated as: 
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Graphics Display Updates 
Communications Driver 
Rocket Guidance Calculations 


Operator Interface (Mouse) 
2.4.1 Graphics 


The graphics updates entailed placing target symbols, rocket symbols, and the targeting 
reticle [cross hairs] on the screen fast enough so that any perceptible motion was not lost 
due to processing overhead. With such a large number of targets and rockets moving, the 
number of screen updates is significant. Essentially, 1235 screen updates must be done 
every second, which allows a maximum of 810 microseconds per update (assuming 100% 
CPU utilization). An update consists of erasing and redrawing a symbol containing between 
§ and 03 pixels. Initial software took advantage of standard software supplied by the 
graphics interfac: manufacturer to draw the symbols. Timing measureraents indicated that 
it took well over a millisecond to draw a simple symbol. As a result, it was necessary to 
scrap the vendor supplied routines, and provide a more customized interface that provided 
better performance. Although the rockets travel fast enough so that they cross a pixel 
boundary (move) every 100ms, the targets often will not move every update (100ms). It is 
possidle to significantly reduce the processing time by taking advantage of this fact, however 
it is still possible for all 100 targets to cross a pixel boundary during a single update period. 
This worst case must be taken into account. From an operator’s point of view, it will not 
matter if some targets are deferred into the next update period, so if the software can ride 
through this “overload” condition for one update, it is possible to reduce the worst case 


processing requirement nearly in half. 
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The machine code statements are used-to implement the Put_Pixel procedure. This 
procedure performs bit manipulations that could not be achieved with the Ada code 
generator, and were required for every pixel displayed (or erased) on the screen. Variable 
shifts were required to select the appropriate bit to set or clear. Although the same effect 
can be approximated with divide or multiply instructions, the execution time is one seventh 


as long when using the shift instruction. 
2.4.2 Communications Driver 


The communications driver must process at least 30 messages per second. After the design 
change to incorporate the Simulator into the BDS program, these communications occur as 
rendezvous operations. They are performed by the extended runtime that supports 
distributed Ada, and use buffer queues maintained within the runtime. Direct access to the 
network is not provided to the application program. If the simulator is redeveloped as a 
separate Ada program, it can either emulate the rendezvous protocol or the BDS can be 
modified to provide the communications with an Ada task serving as the interface driver. In 
this case, the low level interaction with the Ethernet hardware will be shared by the 


distributed runtime and the application program. 
2.4.3 Rocket Guidance 


Rocket guidance calculations proved to be quite time consuming. Initial attempts at using 
Ada fixed point calculations led to frustration due to the fact that on one compiler used, 
fixed point was being emulated using floating point. Fortunately the production compiler 
supported fixed point in a more efficient manner. Previous experience had provided 
warning that it was difficult to get fixed point numbers with a ’small that is not a power of 


two (most implementations restrict representation clauses on 4X’small to a power of two). 
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Ther:fore, it was imposed on the system design that the hardware provided all dimensions 
as a power of two value. For example, the METERS type used to provide battlefield 
position had a delta of 0.125. 


Several application dependent optimizations were implemented to radically reduce 
computation time. For example, since accuracy became very important as the rocket 
approached the target, it was possible to take advantage of the fact that the target could not 
move significantly during the final ingress phase of flight. Normally the motion of the target 
must be accounted for in any targeting system, but since the BDS recomputed target position 
every 100ms, a simple forward extrapolation provided sufficient accuracy to guarantee a 
"hit". This replaced a more complex iterative algorithm which was used to compute the 


angle-to-intercept values. 


Furthermore the tangent function was replaced with a lookup table, the arc tangent function 
witli a rough approsimation function, and the square root function was designed to mn in 


acce; table worst-case time, with better accuracy at closer ranges. 
2.4.4 Gperator Interface 


-The mouse interface has turned out to be one of the more critical components of the system. 
Early tests indicated that poor response time on the mouse resulted in erratic movement of 
the targeting reticle. ‘This made it nearly impossible to lock on a target and would result in 
mission failure in a target-rich environment. Another aspect about the mouse interface that 
makes it complex is the limited hardware support for the mouse. Only a single byte buffer is 
supplied for incoming data. This translates to a lost message if bytes are not read by the 
application software prior to the next byte reception (2 ms). An interrupt task is used to 
accept the data and buffer it for display processing. Care is required to prevent the high 


priority mouse task from being suspended while display processing was in progress. 
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The BDS source code is listed in appendix H along with the interface design documents and 
simulator specifications in appendices B through E. A graphical overview of the top level 


BDS design appears in Figure 1. 
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Figure 1. Top Level BDS Design 
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3. Compiler and Language Problems Encountered 


Currently the "extended" features of Ada are not widely used, and therefore have the 
greatest number of latent anomalies. They should be carefully tested during integration to 
determine their reliability. Note that the vendor was contacted for a list of "known" 
anomalies, and they indicated that no such list was available. In fairness to the compiler 
vendor, their product is believed to be the most advanced Ada compiler of its kind. It is a 
comment on the complexity of real-time systems that there are still many problems with the 
Ada compilers. The runtime executives are attempting to solve many of the issues of 
real-time programming and need to be extremely robust, yet fast. These are two aspects that 


generally work against each other. 


1) LONG_FIXED division was unreliable. Certain numbers (resulting in bit patterns very 
close to 1FFFFh) caused divide error. This manifested itself by causing a 
NUMERIC_ERROR after hours of operation and hundreds of rocket launches and target 


intercepts. 


2) Improper Inlining of code statements. If the last instruction of the calling sequence used 
the same register as the first instruction of the machine code procedure to be inlined, the 


code generator would exchange the two instructions: 


mov = (bp- 10) , ex 


mov = ex, (bp- 20) -- code statement begin 
would become: 
mov οχ, [bp-20) 
mov (bp- 10} ,cx -- reorder, resulted in storing of incorrect vaiue 


Note that this problem appeared after the code in question had already undergone 
successful integration testing. It appeared suddenly after a new re-compilation caused 


different registers to be used (with no changes in compiler switches). 
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3) If an interrupt occurs when the auto-increment direction flag is set, it is not restored 
properly if the interrupt is handled by an Ada task (using the INTERRUPT_HANDLER 
pragma) which makes an entry on anotker task. This only appeared when the system was 
heavily loaded, and periodic rates were set to the full speed. Fortunately the one place in 
the code where the direction flag is set (normally it is cleared) was executed quite frequently 


so the problem could be reproduced, although not in a predictable fashion. 


4) Complex expressions did not generate the correct code sequence. Actual parameters 
containing array aggregates, which in turn consisted of multidimensional array references 
with non-integer subscripts resulted in a failure for the appropriate segment register to be 
loaded correctly. The graphics task takes a parameter list consisting of the old and new 
positions of an object(x,y), the object type (rocket,target, etc.), and a color. To determine 
viz color, an array indexed by the object type i) one dimension and a status flaz indicating if 
it was engaged for intercept was used in the other dimension. This causes target; to "light 
up” when engaged for intercept. However, it did not work and the code was rewritten to 
create temporaries during each step of the expression. The failure mode was to select the 
zero(Q) color - black, which gave the appearance that nothing was working, when in fact 


invisible targets were moving on the screen. 


5) The pragma to establish task storage size did not function. This resulted in the program 
terminating vefore initial elaboration was complete. Basically the program would simply 
crash with no exception trace back (due to the fact that the program had not completed 
elaboration). This required a programmer to single-step through the code to find where the 
problem was. The solution was to use a linker option to set the library stack size, which did 
work although it applied the same stack size for all library tasks. A general comment is that 


it is extremely difficult to determine the correct size required for a task stack. Ideally an 
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automatic approach to setting the stacks would. be supported. It might use pragmas to 
provide maximum call depth information to the compiler. The compiler could compute the 


worst case storage requirement for each task type and allocate their stacks accordingly. 


6) Deeply nested exceptions did not propagate properly. In a task, a loop with an exception 
block called a procedure which had an exception and no exception handler. The exception 
should have propagated to the exception block within the loop (which had an “others” 
clause), but instead propagated to the outermost level of the task, causing it to terminate 
silently. Debug trace statements were placed in each of the tasks but these were not invoked 
when exceptions occurred. The result was either a deadlock, or other tasks getting 


TASKING_ERROR when rendezvous were attempted. 


7) Package Calendar elaboration check was not performed properly. A number of problems 
with elaboration were encountered (due to library tasks starting execution before other units 
are elaborated). One strange problem was due to the fact that no elaboration check was 
performed prior to calling the Calendar.Clock function to establish the periodic start point. 
Apparently the Calendar package body had not been elaborated and the Clock function 
returned the time of a few hundred microseconds into mission time. Then after the calling 
task was suspended for a rendezvous, the Calendar package was elaborated, which set the 
TIME value to some time in 1987 (a very large number). When the task resumed execution, 
it reached the end of its loop and attempted to compute the delay necessary to achieve the 
desired interval. Since the delta time was almost 2000 years, it exceeded the range of 
duration and a NUMERIC_ERROR was raised (although a TIME_ERROR) should have 


been raised. 


8) Calling more than a single entry from within an interrupt task (using pragma 
INTERRUPT_HANDLER) can result in a system crash. Using the rendezvous to signal a 
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background task to continue execution is essential in real-time applications. This 
mechanism may not be reliable on all implementations and special precautions are 


necessary for its use. 


9) Named associations in aggregates generated substantial amounts of additional runtime 
code over using simple positional associations. This was true even if the values were 
Jositionally correct as well. This resulted in having to limit the named associations and to 
put the names in comments following the statements. This had a negative impact on the 


readability of the program. 


The impact of having many failures in the runtime and generated code is demoralizing on 
the engineering staff. It becomes apparent that the most difficult problems to find are those 
of the runtime and generated code, since one expects the Ada statements to work as 
specified. There is a realization that the success of the project is out of your hands, and in 
the hands of the compiler vendor. No matter how good the engineering team is, the system 
will not work if the translation from source to the generated code is incorrect. This is 
unusual for real-time programmers who are familiar with assembly language, where there 


are far fewer discrepancies. When discrepancies do exist, they are much easier to find. 


Finally, a problem that surfaced with the Ada language was a standard way to provide 
atomic transactions that could cross the application code to runtime code boundary. The 
application has a requirement to accept frequent interrupts, buffer the data to a certain 
point (based on the input stream), and then perform a considerable amount of processing on 
the data, while new data is arriving. This is done by having an interrupt task perform the 
buffering, then passing the data off to a background task. The difficulty is that the interrupt 
task may not be suspended (for any reason other than to service higher priority hardware 


interrupts). This implies that a conditional rendezvous is required. However, what is really 
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required is the ability to queue the buffer and request, then signal the background task if it is 
suspended waiting for new data. Essentially there are two approaches to this problem: 1) 
provide a sufficient number of buffer tasks so that they can act as surrogates on the entry 
queue of the background task, or 2) maintain a flag that is only set when the buffer task is 
ready to immediately accept a rendezvous. This requires that the background task disable 
any type of preemption; check if there is more work to do; and if not, perform the accept 
Statement. Presumably the runtime will then allow preemption only after placing the 
background task in a position to immediately accept the rendezvous. The interrupt task 
obviously will not attempt a rendezvous with the background task unless the flag is set. Both 
of these solutions have serious drawbacks. The surrogate task approach requires substantial 
optimization on the part of the compiler and runtime. Furthermore, it may obfuscate the 
intent of the rendezvous. The second approach is very implementation dependent, and is 
prone to error if used by other than very experienced and careful programmers. What is 
clearly needed is an asynchronous form of task communication. This could return to the 
language as revised forms of the "SEMAPHORE" and "SIGNAL" generic tasks defined in 
the "Preliminary Ada Reference Manual" [3]. Although an argument can be made that 
implementations can provide the same effect as these predefined task types, to depend on 
implementation optimizations for such crucial real-time operations is a questionable design 


approach. 
4. Hardware Problems Encountered 


Several hardware problems were encountered during the development of the BDS system. 
For the most part, they presented minor nuisances, but in some cases resulted in days of 


additional testing to isolate the problem. 
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One of the ‘five Ethernet cards used arrived non-functioning. After approximately one-half 
hour of performing various tests, the failure was isolated to a bad "station address PROM". 
This nonvolatile memory holds a unique network address for communication on the 
Ethernet. Upon very close inspection of the PROM integrated circuit, it was noticed that 
one of the pins had been bent under the chip. By removing the chip, straightening the bent 


pin, and reinserting the chip, the problem was solved in a few hours. 


Tue 80386 computer card has a VLSI chip (80C206) used to control interrupts, timers, and 
several other features in the computer. Οἷα reature that was used to obtain accurate clock 
values was a‘ mode which latches the two bytes of the 16-bit counter as well as a status 
register simultaneously. This is necessary because the counter is changing value every 418 
nanoseconds and getting reliable values is difficult without such a latch. Unfortunately, the 
latcn did net work. The programming of these chips is extreinely complex, and the first 
assumption wien something fails is to suspect the software that interfaces to the chip. The 
documentation was rather vague, and as a result approximately two days were lost until it 
was concluded that the chip may be bad. Note that the timers worked fine, and the rest of 
the chip’s thousands of transistors apparently worked fine as well, so hardware failure was 
not suspected. The only failure symptom was that once in a great while, a time would 
appear to jump backward by a small decrement. This was due to reading one byte while the 
status of the other bytes changed. By trying the exact same software on another computer, it 
was determined that there was indeed at least one bad gate on the 80C206 chip. A 
replacement chip was ordered and when it arrived, it did not work at all. A month later the 


second replacement chip did work, and solved the timing problems. 


Although not strictly a hardware failure, the documentation describing the Ethernet 


hardware had numerous errors. Weeks were spent trying different initialization sequences 
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in an attempt to debug the network drivers. For example, the board has an on-board 
network transceiver, and may alternatively use an externally supplied transceiver. The bit 
that controls which transceiver is usea was incorrectly specified in the documentation. It was 


pretty much an act or desperation that aliowed ihe error to be found. 


Likewise, the technical manual on the mouse, incorrectly specified jumper settings which 
establish the communication protocol between the mouse’s processor and the BDS 
processor. Once again, it was trial and error until something worked, and the error 


condition could be verified. 
5, Distributed Ada 


Note that while multiprocessing may be used to help solve the performance problem 
associated with Ada, it is not a cure-all. Developing software using inefficient algorithms 
and then trying to apply a large number of processors in order to get the desired 
performance is not suggested as an appropriate design method. Suitable algorithms can 
make a much more significant impact on performance than adding several processors. The 
additional processors should be regarded as a fine adjustment on the performance rather 
than a simple multiplier. This is dictated by the fact that the recurring cost of hardware, 
while continuing to fall on a cost/performance basis, is still not inconsequential. While 
adding another processor cannot compensate for poor software, it can more than 
compensate for some efficiency lost because of immature compiler technology. If the high 
level language can take the complexity out of the distribution effort, then the result is a 


system that will perform better and cost less over the life of the system. 


5.1 Definition of Terms 
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The term "Distributed Processing" is frequently used, and often with meanings that imply 
radicaily different architectures. For this reason, the use of the term within this paper is 


explicitly stated, 


Distributed Processing, for the purposes of this project, shall be defined as: "a 
multiprocessor system characterized by having communicating autonomous processors, 
where the communication response and throughput are significantly lower than local 


memory access”. 


"Significantly" in the above sentence implies a difference that is greater than an order of 
magnitude. The essential aspect of this definition is the recognition that program 
performance of these systems may be radically altered by changes in configuration. In 
particular, when functions that interact within a processor become separated onto two or 
more processors, the communication overhead can be dramatic. Therefore, in general, 
ralate:: functions separated by a processor boundary tend to be loosely coupled with each 


other. 
5.2 Project Objectives 


One of the principle project objectives is to determine how Ada tasking can be used on a 
distributed system to improve total system performance. There are many advantages to 


using the Ada tasking model as the sole abstraction of concurrency. Among them are: 


1) The ability of the compiler to check interfaces between physical processors. 


2) A consistent eee to parallelism - all concurrent activities are expressly stated with 
a consistent formal mechanism making the system less complex. 


3) Re-configuration is facilitated, since the interface between communicating tasks on a 


processor is the same as that among separate processors, thus allowing tasks to be 
migrated more easily. 


-19- 


Demonstration Project Final Report 


4) Consistency helps to make distributed testing and debugging more easily supported by 

compiler implementers. Ad hoc approaches make debugging tools prohibitively 

expensive. 
Several studies have implied that the synchronous rendezvous required by Ada is not 
practical for real-time distributed systems [report to Real Time workshop at IDA, July 
1988]. This conclusion is drawn because of the communication required by the Ada 
semantics creates tremendous overhead in the network-based systems studied. Typical 
round-trip communication times were measured at 20ms for a single message/acknowledge, 
of which several might be required for Ada’s rendezvous semantics. These numbers were 
presented as being processor, operating system, and network independent. The work of this 
project implies that the message transfer times are distorted in many of these studies by the 
unnecessary overhead associated with message presentation to the network. In every case, 


2 is used rather than direct 


an intervening operating system such as UNIX! or iRMX86 
interaction of the runtime with the network interface. These operating systems do not 
provide high performance pathways for user programs to access network facilities. 
Overhead is incurred by requiring a context switch between User and Privileged mode, and 


often a full process switch for every message transmission/reception. 


Furthermore, additional network protocols such as TCP/IP are used, and packets are often 
manipulated by a “smart” network interface card which results in actually slowing down the 
communication. Studies done on a previous project indicated that it is possible (in a lightly 
loaded Ethernet system with commercially available hardware ) to perform the following 


steps in under two (2) milliseconds: 


IUNLX is a trademark of AT&T 
2iRMX86 is a trademark of Intel Corp. 
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1) call a procedure requesting a block (512 bytes) of data, 
2) generate a packet with the request for data, 
3) transmit the request across the network to a server processor, 
4) server processor interprets the request (disk read), 
5) read the data from the disk (1ms), 
| 6) transfer the data back to the requester, 


7) the requester accepts the data, and is ready to issue another request. 


Since a 2:1 interleave was used on the disk, the effect was to achieve the same data rate from 
the remote disk as what was available on a local disk (identical hardware). This is due to the 
fact that with a 2:1 interleave, there is a millisecond delay (actually 980 usec) between 
reading one disk sector and the next. The disk is formatted this way to allow the operating 
system enough time to read the next sector before it is micsed and a full rotation is required. 
The ‘icveloped software was able to perform the two way communication across the network 
during the 980 microsecond inter-sector delay with enough time left ove: to setup for the 
next operation. The software overhead associated with the network was under 380 
microseconds, since the actual transfer time on the network for ἃ 512-byte packet and a 


64-byte packet was approximately 600 microseconds. 


The point in the discussion above is that people may be rejecting distributed Ada unjustly. 
Similar to the indictments of Ada that came about with initial releases of compilers, the 
initial studics of distributed Ada are based on prototype implementations and are built in a 
way that is unlikely to be used in a real-time system. It is essential to accurately determine 
what the penalties of a synchronous protocol are prior to rejecting the Ada rendezvous 
model as being unsuitable. Once the requirements imposed by Ada are clearly understood, 
it may be possible to support these requirements more efficiently in hardware, and thereby 


nearly eliminate any penalty associated with using the Ada tasking model. 
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One point that cannot be ignored is the substantial difference in overhead associated with 
various tasking combinations. In particular, the presence of an abort, timed entry, or 
selective wait with either a terminate alternative, or a delay alternative greatly complicate 
runtime processing. In addition, the reliability of the network (transmissions are not 
guaranteed) also increases overhead substantially. This project has shown that a simple 
rendezvous in an error-free environment is achievable on commercially available hardware 


in under lms. 
§.2.1 Unit of Distribution 


Parallel systems research often concentrates on how to achieve parallel computation of a 
process that is described in a serial language. Great effort is applied to detecting 
independent calcutations and executing them on separate processors. Claims are made that 
the program design must be fundamentally changed in order to achieve good performance 
on different parallel architectures. Our findings are that, while this is true for the general 


class of computer programs, it is not so typical of embedded applications. 


Embedded applications, because of their interaction with several real-world events, tend to 
have natural parallel threads of control. In fact, programmers of such systems often try to 
artificially reduce the number of parallel threads in their programs because of the overhead 
associated with switching between threads. In these cases, they combine two or more 
threads. For example, in an aircraft computer where a response to pilot commands must be 
processed within SOms, and new inertial data is received every 40ms, the program might 
check for a new pilot command every time the inertial data is received. This combination of 
threads insures that the pilot is monitored frequently enough to meet specification. The 
result is that the code has been convoluted by the need to achieve a “low-cost” context 


switch. Furthermore, the pilot input is being checked more frequently then necessary, and 
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yet will still incur an average 20ms delay. Ideally a separate task would be created for both 
functions, and they would only execute upon (interrupt from) receipt of pilot command or 
inertial data. However, the context switch associated with the ideal approach may cause the 


program to miss deadlines in the presence of a large number of pilot commands. 


With the latest generation of Ada compilers, this context switch overhead is being 
substantially reduced, and therefore it is practical to express “naturally” parallel activities as 
Ada tasks. Since the expression of the dependencies of such tasks (parallel threads) are 
clearly indicated by entry calls and accept statements, the program can be distributed in a 
straightforward way, provided that the semantics of the Ada tasking model are faithfully 


preserved for Ada rendezvous and shared variables. 
6. Distribution Implementation Details 


1’ ¢ Distributed runtime code is composed of five modules: the Rendezvous Services, 


Linkage Code, Network I/O, Network Setup, and a small Vendor Runtime {nterface. 


The Distributed Rendezvous Services provided the initialization, remote elaboration start, 
remote entry, local entry, selective wait (among either local or remote tasks), remote start 
accept, remote end accept, and local end accept. Additionally, routines were provided that 
execute at interrupt level to respond to incoming messages. These include: begin elaborate, 


end elaborate, request entry, and accept complete. 


The Linkage Code provided additional information such as the length of parameters for the 


distributed rendezvous calls that is not normally necded for tasks that share memory. 


The Network I/O and Setup modules provided direct interface to the Ethernet hardware. 


All protocol management and packet construction was performed by this software, as well as 
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direct initiation of packet transmission -and interrupt response upon completion of 
transmission or packet reception. Buffers were allocated and deallocated from a fixed size 


buffer pool for efficiency. For example, buffer deallocation time was under 5 microseconds. 


Packets contained the normal 48-bit destination and source addresses, a field termed 
“receive control pointer", packet priority, sequence number, and total packet length followed 
by parameter data. The receive control pointer (RCP) was used by the receiving processor 
to determine how to process an incoming message, which task and/or entry is referenced, 
and to locate the proper reply message header. Use of these pointers reduced the amount of 
information necessary to be transmitted, and provided quick access to statically created 


packet headers. 


The Vendor Runtime Interface module provided addresses for standard P and V semaphore 


operations used to “wait” and "signal" task execution. 
P gn: 


The distributed runtime was developed using assembly language to be compatible with the 
vendor’s runtime, and to more accurately determine what could be achieved rather than 
allow possible high level language inefficiencies from biasing the results. Future work would 
probably benefit from an Ada implementation, and it would be interesting to compare the 
relative performance of the two approaches. Refer to Appendix I for source code of the 


distributed runtime code. 
7. Distribution Issues 
7.1 Language Issues 


The Ada Standard provides a degree of confusion as to what semantics are required in 


distributed systems. Examples and possible solutions for these situations are: 
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1) Timed Entry Calls - The Ada language reference manual (RM) implies that the 
rendezvous will be cancelled if it cannot begin prior to the delay specified. This leads to 
confusion on a distributed system where the delay may expire prior to being able to request 
a rendezvous with a remote task. But the Ada semantics would have permitted the same 
rendezvous to occur if the delay were 0.0 or negative, since in this case the semaitics of the 
conditional entry call are used. It is pretty clear that the desired semantics are to ALWAYS 
attempt the rendezvous, regardless of the delay specified (like a conditional call), and if the 
server is not at a corresponding accept, then wait the specified delay prior to cancelling the 


call. 


2) Package Calendar - Although no explicit confusion exists, programmers may be misled by 
the simplicity of the discussion on TIME. The time of day is expressed as the number of 
seconds (presuniably since inidnight local time). This is contrary to many embedded systems 
w'tch uperate on Mission Time or Universal Time (Zul), although this is still possible with 
the current definition of Ada. What is perhaps missing is the ability iv update the sysiem 
value of time. This problem is especially acute in distributed systems since they frequently 
operate from independent oscillators. This results in synchronization being required at 


initialization and periodically thereafter due to differences in clock rates. 


Application software within tasks frequently time-tag information indicating when the data 
was sampled from the external device. If this information is then transferred to a remote 
task operating on a separate clock, the interpretation of the time-tag is likely to be faulty, 
resulting in error or even system failure. Time is further complicated by the need to 
synchronize, because it will result in some of the clocks being forced to jump forward or 
even backward in time. This noncontinuous aspect of time makes synchronization in 


distributed systems very complex. It is suggested that package Calendar be expanded to 
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support applications modifying the system value for time. Clear semantics must be specified, 
especially with respect to not impacting any delays currently pending. Ideally, discontinuity 
in time should be allowed to “creep back on schedule". That is, an epsilon time would be 
provided to the runtime system, which would gradually advance/retard the clock at a 
specified rate until the epsilon was eliminated. For example. if the clock was determined to 
be 500 microseconds behind real time, an epsilon of 0.0005 would be specified with an adjust 
rate of 0.001. This would imply that the clock would be accelerated at a rate of 0.1% (1 
micro second per millisecond) until it was on "real" time. This prevents significant errors 
during computation of elapsed time. Another approach is to have each processor maintain a 
continuous increasing mission clock which is used to compute elapsed times and to translate 
mission time to time-of-day whenever necessary. In this type of system, each processor 
keeps an adjustment of time to correct differences between any other processor with which it 
communicates. Obviously a common clock stream going to each processor is a preferable 


solution to any of the above if the system architecture supports it. 


3) A Failed Processor Node - The principle designers of the Ada language have stated that 
the Ada language does not specify what happens in the event of a hardware (CPU or 
memory) failure. This makes tremendous sense from the point of view that no set of 
instructions can have meaningful semantics if the underlying hardware is unable to execute 
the instructions correctly. However, when a program is distributed over multiple processors, 
and one fails, the integrity of the other processors is not necessarily compromised. They 
could conceivably continue to function correctly and it might be appropriate to know the 
semantics of any interaction with tasks or data on that failed processor. It is suggested that 
the semantics of such a failed processor node be identical to those of a task which has an 
unhandled exception. That is, the task will go to completion. Any clients in a rendezvous 


will have TASKING_ERROR raised at the point of call. For shared data on that node, a 
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new exception should be defined, such as ACCESS_ERROR, which will be raised when any 
access to storage fails. Note that this is different than STORAGE ERROR in that the 
latter is only raised when available storage is exceeded. Recovery from the two types of 
faults is likely to be different. The ACCESS ERROR might also be appropriate for 
memory errors on the local node as well. Finally, in fault tolerant applications where a node 
may come back on-line after a failure, ACCESS ERROR might be a more general 
approach to reporting an error during rendezvous than TASKING_ERROR. This would 
allow a node which was intermittently accessible due to communications problems to 
continue to operate rather than require otherwise healthy tasks to become completed. In 
these situations referencing the TERMINATED and ’CALLABLE attributes while the 
node executing the designated task is unreachable would also raise ACCESS ERROR. 


4) Package System - prohibits two separate representations of a system dependent type 
within the same program. This causes diificuhy in distributing a single program among 
heterogeneous processors. A solution might be to create a function "Processor" which 
returns a static enumeration type (Processor_Type) indicating the processor the program is 
actually executing on. Each of the named numbers in package system could be changed to 
be a function which returms a static value and takes a single parameter to select the 
processor. The default parameter for the function would of course be the "Processor" 
function. Types ADDRESS and NAME could similarly be referenced by 
ADODRESS’CPU(Processor_Type) which returns the type of ADDRESS on the specified 
processor, Once again the normal types for ADDRESS and NAME would be preserved and 


would refer to the executing processor. [This solution may need tightening up.] 


5) Priority preservation by the network is an issue that should be addressed in future 


language revisions. The term "available processing resources” in RM 9.8(3) can also include 
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the network, since it may be managed by the Ada runtime. The RM should clarify if it is 
acceptable to have a high priority task blocked waiting for low priority tasks to perform 
network transfers. The preferred approach is to require implementations that support 


priorities to also have the priorities apply to network scheduling as well. 
7.2 Issues Addressed By the Demonstration Project 


Essentially every paragraph of the RM Chapter 9 (Tasking) has an impact on distributing 
Ada programs as Ada tasks. Achieving predictable timing in a distributed Ada application is 
also a major concern. This implies the ability to maintain task priorities in network 
transactions. Most commercially available network hardware does not support preemption 
of message traffic to higher priority messages. This results in a high priority task being 
blocked while lower priority tasks transfer data (sometimes referred to as Priority 
Inversion). Special care must be taken to avoid this effect and to guarantee response time to 


high priority tasks. 


The issue of shared memory has frequently been addressed by totally restricting its use. 
Although the demonstration project did not need distributed shared variables for the initial 
prototype, their availability would give greater generality to what can reasonably be 
distributed. Some analysis was done however to determine what might be needed to support 
such variables. The approach that would be used to implement distributed shared variables 
would be to assign them to segments which could be mapped as “not present" by the memory 
Management system in the processor. The segment descriptor tables are then programmed 
to recognize segments of "Network Data", and if the data is not resident, result in a page 
fault. This page fault results in suspension of the task and a network message requesting the 
data being multi cast to all processors which access that segment. The node having the data 


marks its segment as being not resident and transmits the data segment to the requester. 
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- Upon receipt of the data, the requester marks its segment as resident and makes ready the 
suspended task for execution (possibly preempting a lower priority task). It is essentially a 
complicated version of virtual memory, utilizing the virtual memory support provided by the 
80386 processor. Several types of Network Data are envisioned: Simple Static data that 
does noi migrate; Migrate-able Data as described above; and Replicated Data that is 
available locally in read form on all processors, but can be written only by a single master, 


resulting in a broadcast to all interested nodes. 
7.3 Deferred Issues 


The following issues deserve immediate attention but are well beyond the scope of this 


project. 


Load Managenient - dynamic task migration to provide the desired loading 
Fault Tolerance - Detection, Isolation, Roll Back and Recovery, etc. 

Design Issues - Paradigins for a "good" distributed design 

Analysis of Distributed Behavior - Predicting overload conditions, deadlock, etc. 


Limiting the Impact of Changes in Distributed Systems - how to compensate for different 
performance because of configuration. 


Incremental Upgrades While On-Line (Never-Stop) - dynamic binding of Ada name 
space. Maintaining system state in the presence of "μον" objects. 


Debugging - synchronous halting of all processors and system clocks. Providing 
“transparent” network debugging support. 


Heterogeneity - common interchange formats, negotiation of desired formats between 
processors. 


Security Barriers - Maintaining multi-level security among secure processors. Data 
labeling, real-time encryption, trusted network software. 


Network Interface Standards - What impact does "required" compliance with OSI (Open 
Systems Interconnect), MAP (Manufacturing Automation Protocol), or GOSIP 
(Government OSI Profile) have on real-time systems? Is compliance desirable? 


7.4 Architecture Support 
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In order to achieve optimal support for distributed Ada applications, new architectures will 
be necessary that closely relate to the Ada semantics. Although this topic is also beyond the 
scope of the project, several ideas regarding ideal architectures have come to light while 


performing work on the project, and are partially documented here. 


For processors that can be connected via cables, an ACTIVE STAR network may provide 
good solutions to many of the distributed Ada problems. Since there is a need to provide a 
common sense of time among distributed systems, the star hub could be continuously 
transmitting data to and from each of the nodes. This data stream would serve several 
functions. The first function would be to supply a common and constant clock stream to 
each of the nodes. The second function would be to provide constant status on the health of 
each node. Ifa node fails, a watch dog timeout on the interface card would trip and halt the 
data stream to the hub. This would result in a "Failed" status at the hub. Obviously the data 
streams would also serve to transmit data to and from the hub and other nodes. Control 


information embedded in the stream would indicate what should be done with the data. 


The hub design is absolutely critical. To leave out functionality would result in significant 


performance degradation. As a minimum, the hub should support the following capabilities: 


1) It should be able to be replicated to provide N-version fault tolerance. 


2) It should preserve the priority of the task requesting the transfer for all network 
transactions. 


3) Network Data Store (NDS) should be provided to cache shared variables and to hold 
the necessary data to resolve inter-processor tasking states. 


4) The NDS memory should be high speed (under 35ns) and should be time division 
multiplexed among all nodes, simulating a multi-port memory. 


5) Access to the NDS memory should include primitives for indivisible operations such as 
test and set, and atomic ADD and QUEUE operations. 


6) Security provisions should be included to electrically prevent data labeled as classified 
from being transferred to a node of lower classification. 
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7) Node interfaces to the network should appear as memory in the processor address 
space. Task control blocks for tasks which have remote communications should be 
located in this memory, which is maintained to be consistent with the image at the hub. 


8) Node interfaces should contain a 64-bit mission clock that can be reset simultaneously 
with all other nodes, stopped simultaneously with all other nodes, and is clocked 
simulianeously with all other nodes. In addition, the interface card would have a 32-bit 
40.233usec clock which would be used as a DURATION sf delay device. Rather 
than interrupting the CPU at a regular period, the timer would be programmed with the 
shortest delay currently pending. This would provide very accurate delay timeouts, 
without incurring overhead when delays are not being set. To eliminate the software 
overhead associated with determining the proper value for the timer, custom hardware 
could be supplied that would accept a delay value and a task ID. The hardware would 
support up to 128 delays directly and allow software to resolve any delays beyond 128 (at 
most one “true” delay need be set by any task). The sce delay would be added to the 
64-bit clock and an absolute time saved in a register file sorted according to increasing 
time. If the newly requested delay is earlier than the earliest delay set, its time would be 
subtracted from the 64-bit clock and the resulting value placed in the count down timer. 
As times expired, the earliest time would always be placed in the timer. The task ID 
would serve to notify the runtime as to what delay timed out (along with an interrupt on a 
programmable level), and to allow for cancelling of the delay. of the clock circuitry 
could easily be supported within a current technology gate array. 


9) Built in Test provisions should be included in the hub. 

10) Debugging support, including simultaneous halting oi all nodes (via non-maskable 

interrupts from interface card) should be an option for hubs. The halt would also serve 

to disable counting in all node clocks so thai perceived real-time is uninterrupted. 

Obvious features such as data logging of "meaningful" data should be conducted at the 

hub. 

11) Provisions to provide network manager coutrol from one or more privileged nodes. 

rhis might include getting network status, forciny a clock synchronization with a new 

Mission time, broadcasting data, or shutting off other (wayward) nodes. 
Such hub designs are believed to be practical with current technology for reasonable sized 
networks (under 32 nodes, however each node could be a cluster of processors or a gateway 
to a hierarchy of other nodes). A typical medium might be fiber optics for long haul 
applications or coax cable for shorter runs, Data rates of 100Mb/s could easily be achieved 
using 125MHz modulation with 5B/6B codes. The effective throughput should exceed 
12MB/sec with propagation delay times typically under a microsecond in the absence of 


contention. 
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8. Timing Analysis - 


Timing information was collected for several purposes. First, to insure that the program was 
operating correctly and to help isolate the source of timing problems. Timing information 
was also essential to evaluate the effect of optimizations. Finally, accurate timing 
information was necessary to compare the relative performance between the single and 


multiprocessor versions of the application. 


Timing information was obtained with three techniques. The first technique used a 
preprocessor to insert procedure calls to a time stamping routine. These were inserted 
throughout tHe program at every procedure entry and exit point, as well as task rendezvous 
points. In addition, the runtime was modified to make a call to the time stamper whenever a 
context switch occurs. This made it possible to recognize when a task is preempted, and 
avoided incorrect charges of execution time. An example listing resulting from a time stamp 


execution trace appears in Appendix G. 


The time stamp mechanism places timing information as well as a unique identifier in a 
circular buffer during execution: This buffer was set at 64K bytes and used 8 bytes per time 
stamp. It “wraps” every 8192 time stamps, overwriting previous time stamps. This allowed a 
trace back of several 100ms cycles through the program from any stopping point. It was 
possible to edit the pre-processed source code to selectively enable/disable time stamps 
which extended the trace back up to several minutes. Additionally, it was a simple matter to 
disable all time stamping by replacing the stamping procedure with a “return” instruction. 
Since the time stamp procedure requires slightly over 20 microseconds, using it did intrude 
on program execution. Often only one or two time stamps were enabled to provide accurate 
timings without significant perturbation of the program. The clock used had a resolution of 


419 nanoseconds and is software extended to 33 bits. 
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The second approach to timing was used to measure aggregate processor utilization. This 
technique involved use of custom hardware that permitted starting and stopping one or 
more processors simultaneously. Essentially, a separate communication signal was 
configured that could invoke a non-maskable interrupt (NMI) in each of the processors. 
This line was activated by a dedicated "timing" processor which would initially signal the 
processors being timed to start, then signal again, to stop the processors. Each processor 
would increment a counter within a tight loop during their "idle" time. The value in the 
32-bit counter would provide a measure of the amount of time spent in the "idle" loop. As 
processor saturation occurred, the counter would not increase beyond those counts that had 
accumulated during initialization (prior to reaching a steady-state load). After close 
analysis, it was determined that the "idle" loop value is not valuable in the distributed system, 
because this is where the processor waits for communication. The “idle” time therefore gave 


ἢ false impression that deadlines could be met. 


The best indication of meeting deadlines was the third method of timing. To support 
periodic processing, each task computes the amount of time necessary to delay before the 
beginning of the next period. The durations computed were saved in a buffer using an 
“pp oach similar to the time stamping technique. The most time critical task: 
"ROCKET.CONTROL" was monitored in this way to record how close it came to the next 
deadline. If the duration became negative, it was a clear indication of an overrun condition. 


That is, the time for the uiext period had already passed. 


Times weie collected for single and distributed processor configurations and are reported in 
Figure 2. The distributed system has two processors connected by a 10 Megabit per second 
Ethernet link. The results clearly indicate that the remote rendezvous can be completed in a 


reasonable time, even with large transfers of data required for in out parameters; and that 
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there is a substantial performance benefit.to distributing the program. This scenario with 
the distributed architecture allows 12 airborne rockets to be processed before deadlines are 
missed, while the single processor architecture can only support 7 rockets without deadline 
overrun. This is indicated by the point at which the available time prior to the next period 


becomes zero. 


Figure 3 shows the times in microseconds required to perform the actual intertask 
communication using the distributed runtime. Note that the overhead roughly approximates 


a fixed portion of 175υ5 and a data transfer of 1 byte every 4.03us. 
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΄ 


WUMBER OF ROCKETS 


0 5 10 15 20 


PROCESSOR 
Single CPU 97 ms 3ims -37ms -87ms -102ms 
Distributed 95ms 6ims 27ms o4ims -69ms, 


Figure 2. Available Time prior to 100ms Deadline for Rocket.Control (25 Targets) 


Rumote Rendezvous Microseconds 
a parameters 490 
1 out parameter 202 bytes 990 
1 out perameter 1002 bytes 4214 


For the 1002 byte rendezvous, the breakdown is as follows: 
Message setup /transmit and context switch 110 


total distributed runtime execution including 
round-trip message transfer and second context switch 3737 


Out perameter copy after reception (end rendezvous) 367 


Figure 3. Rendezvous Timings 
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9. Principle Findings 3. 


The Ada rendezvous model is practical (although not necessarily ideal) for distributed 
communication. Unconditional rendezvous with small parameter lists can be achieved with 
off-the-shelf communication hardware in under 1 ms. Although this is significantly higher 
than the 100us required for local rendezvous, it is still acceptable for many applications. 
More complex rendezvous mechanisms such as timed entry calls and selective waits with 
delay alternatives impose substantial additional overhead. As with non-distributed 
applications, the synchronous nature of the Ada rendezvous imposes additional task 


constructs in order to “uncouple” many inter-task communications. 


Although Ada compilers now are near to being "full" implementations of the language, the 
most complex features are not yet reliable enough for life-critical applications. Errors in 
runtime code are still too prevalent. These errors are extremely difficult to detect because 
they only occur during particular coincidences of events. A general example is the execution 
of some particular sequence of instructions at the exact moment an external event invokes a 
context switch. This sequence utilizes an infrequently referenced flag within the processor. 
If the state of the task is not fully restored after the context switch, the particular sequence 
may fail to operate correctly. This type of error may go Ἐν ΡΝ after years of operation, 


only to result in total system failure at a particular instant. 


The execution rate of both generated code and the runtime code is considerably better than 
that of compilers of 1986. However, checking code remains verbose. This will tempt 
real-time application developers to suppress the checks, which has a consequence of taking 
different paths through the code generator. Since these paths may not have been tested as 
thoroughly as the primary path (generating checks), the resulting code is likely to be less 


reliable. 
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The speed improvement of distributed Ada is not necessarily scalable. Although the parallel 
naiure of embedded applications make them ideal for multiple processors, the individuals 
tasks are not usually balanced in processor loading. On a shared memory multiprocessor, 
scheduling can occur on a “next available processor” basis but this is usually not practical) on 
a distributed system due to the locality of data. The "vectorized task" is a partial solution to 
this problem. To implement the guidance operation for up to 20 simultaneous rocket 
trajectories, an array of tasks was used. The actual size of the array was controlled by a 
configuration parameter. Each task in the array was passed a list of rockets to guide. If 
additional processors became available, the size of the array could be increased and the 
tasks could be distributed. The size of the individual WORK lists for each task would 
decrease correspondingly. This achieves a “near scalable" performance increase as 


processors are added. 


T.chuniques for achieving distributed Ada via pre-processing the source code, or 
post-processing the generated code/runtime are acceptable for research, but unlikely to be 
so for any production environment. What is required is an integrated compiler/linker/tester 
that supports distribution of programs. A flexible compilation system would support several 
different levels of distribution. The same compiler could target a single processor, a 
shared-meinory multiprocessor, or a physically distributed network of nodes, consisting of 
either single or multiprocessors. This would give substantia! reconfiguration capability to 
system designers. Support for heterogeneous processors would additionally allow 
customization of the configuration to provide the best match of processing resources for 


application requirements. 


Some aspects of the Ada language definition are silent about what should happen in a 


distributed system. For example, if a node fails, should future rendezvous to a task in that 
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node get TASKING ERROR or simply deadlock? What about a rendezvous already in 
progress with a failed node? What if the node fails, but then returns to service? These are 
all likely scenarios in typical distributed systems. A clear statement about what can be 
expected in these situations (or possibly control over what happens via pragmas) is necessary 
in future language revisions. Another area is the interpretation of the timed entry call. If 
the delay duration is > 0.0 and yet the delay expires prior to a message being sent to the 
remote task, should the rendezvous be terminated even if the accepting task is ready for an 
"immediate" rendezvous? Refer back to section 7.1 "Language Issues" for more detail and 


other areas of concern. 


A software manager should not use Ada on a serious real-time project without source code 
to the runtime system. This is not for the purposes of modifying it, but rather to understand 
the detailed execution when necessary. This information is not available in even the best 
vendor documentation (which is sometimes incorrect anyway) but can only be verified by 


examining the source of the runtime. 
10. Summary 


This report discusses the advantages and issues associated with using the Ada tasking model 
for real-time distributed systems. A case is made for reducing the overhead of the remote 
rendezvous (and shared variable access) so that its use becomes practical. Some issues 
regarding the clarity of the Ada Standard are presented and possible interpretations are 
suggested. Several open issues are listed as areas that require further study. These issues 
such as fault tolerance, security, and dynamic re-configuration are extremely complex taken 


one at a time, and become even more complex in any combination. 


Demonstration Project Final Report 


A real-time demonstration project is described and was used to evaluate the effectiveness of 
the distributed Ada tasking approach. It also served to shed light on other implementation 
issues with Ada not associated with distribution. The demonstration software should prove 


helpful to other projects wanting to evaluate real-time performance, or to evaluate the 


capabilities of compilation systems with respect to real-time embedded applications. 
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12. Appendix A - Specification for the Border Defense System 


‘Lhe following document contains a description of a hypothetical battle management system 
used to defend a border. The purpose of this description is to act as a low level system 
specification for the development of software to implement such a system. This software 
will be used to assess the feasibility of use distributed Ada tasks on multiple processors 
using a "source transformation" approach. The assessment will be geared tcwards real-time 
systems, and therefore the hypothetical system contains aspects that will fail totally if not 
processed in the allocated time period. 


in support of the real-time analysis of the system, a combined Target Generator and Rocket 
Simulator will be developed to provide inputs to, and process outputs from the Border 
Defense System system. Although the code in the simulator ‘vill also be written in Ada, its 
development will not be analyzed as part of the study. 


12.1 Overview 


The Border Defense System (BDS) is designed to protect a defined border against invasion. 
It accepts target position information from a surveillance system, and generates a real-time 
color graphics display for an operator to observe battlefield activity. The operator selects 
targets by positioning a target reticle with a pointing interface and pressing an "fire" button. 
These selected targets are then engaged by the BDS, which will launch a rocket and provide 
real-time guidance data for the rocket to the point of intercept. The graphics display is 
updated to indicate progress of the rocket flights (as reported by encrypted rocket messages) 
in real-time. Post attack assessment information is provided to the operator as well as the 
number of active targets and rockets. 


12.2 Requirements 
12.2.1 Target Display 


The target display shall support a minimum of 350 x 500 piciure elements (pixels) of 
resolution, with a minimum of 16 simultaneous colors selected from among a mininium of 
256 colors. The display shall be mapped to a battle area of 4km x 4km. The BDS shall 
support displaying a minimum of 100 simultaneous targets. Target Report messages will be 
provided to the BDS from the Sensor Subsystem at a rate of 10Hz. Each report message will 
contain up to 100 target reports as specified in the Sensor Interface Design Document 
(IDD). These target reports contain target information including the target identification, 
classification, and position. Targets shall be displayed at the position on the display 
corresponding to their reported position on the battlefield. Target symbols shall be current 
within 250ms. Target symbols shall consist of a minimum of 8 contiguous pixels and shall be 
color coded to indicate target classification and engagement status. Multiple targets that 
np to the sasne screen position may appear as a single target or overlap. 


12.2.2 Operator Commands 

The BDS shall Support input from an operator in the form of messages from a hand 

operated pointing device, containing a minimum of three control buttons. The current 

position of the pointing device shall be superimposed on the display in the form of a 

targeting reticle and shall be current within 50ms. The targeting reticle shall consist of the 

corners of a square box (minimum side of 10 pixels) with cross hairs in the center. While in 
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"manual" mode, if the operator presses the "fire" button, the BDS shall command the Rocket 
Control System to launch a rocket, and will track the target closest to the pointing position 
for interception by that rocket. Targets that are engaged shall change color so as to ol ered 
brighter. If more than 20 rockets are active, the "fire" button will be ignored. Pressing of the 
“reset” button shall result in battlefield cumulative statistics being cleared. The third button 
shall toggle the BDS between manual and automatic modes. In automatic modes, the "fire" 
button shall be ignored, and target engagement shall be selected Mi the BDS. The target 
closest to the protected border shall always be selected. By default, the MANUAL mode 
shall be selected upon system initialization. Pressing of any single button shall result in the 
desired action within 250ms. When more than one button is pushed simultaneously, they 
shall be processed in the order of MODE, FIRE, and RESET. 


12.2.3 Rocket Control 
12.2.3.1 Encryption (Phase IT) 


All rocket data link messages shall be encrypted according to the Data Encryption Standard 
(DES). Encryption/Decryption shall be done on all rocket reports and rocket guidance 
update data within the messages. Other fields shall be transmitted as plain text. Key 
management shall be in accordance with "Key Control for the Border Defense System" 
document (Appendix J). 


12.2.3.2 Rocket Reports 


Rocket report lists will contain up to 20 rocket reports that have been collected by the 
Rocket Control System and transferred to the BDS via the Rocket Data Link. The format 
of the received report lists is specified in the Rocket Data Link Interface Design Document. 
Rocket report lists will arrive at the BDS at a 10Hz rate to provide new position data for 
each active (in flight) target. 


12.2.3.3 Rocket Guidance 


Rocket guidance lists shall be generated at a 10Hz rate and will contain new attitude control 
data for each rocket in flight. These lists shall be transmitted via the rocket data link to the 
Rocket Control System for up-link to the rockets. Each rocket will be assigned a unique 
(with respect to all in-flight rockets) identification number by the BDS. Upon recognition of 
a new rocket ID, the Rocket Control System will launch an additional rocket (up to 20 active 
rockets). Failure to provide rocket guidance data for each rocket within 100ms will result in 
the rocket performing an automatic self destruct (due to concerns about countermeasures). 


12.2.4 Battle Status 

Battlefield conditions and statistics shall] be continuously displayed. At a minimum, the 
numbers of active targets and rockets, total numbers of targets destroyed and rockets 
expended since the last reset shall be reported on the or e display will also clearly 
indicate the mode of operation (AUTOMATIC or MANUAL). Battle status shall be 
current within 1 second. 


12.3 Performance Requirements 
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The BDS shall provide 100% hit rate while operating in the absence of effective 
SUSHI and with the conditions specified in the Parameter Data Base (Appendix 


12.4 Quality Assurance Requirements 


The BDS Software shall be developed in the Ada language (ANSI/MIL STD 1815A-1983) 
in accordance with Defense System Software Development standards (MIL-STD-2167A). 
No assembly language is permitted. Ada "CODE" statements may be used, but are limited 
to 50 code statements. A Contracting Agency oi act coding style guide (Appendix F) 
shall be adopted and adhered to in production of all deliverable code. 
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13. Appendix B - Parameter Data Base ~- 


package P08 is 

τῷ This peckage specifies the Parameter Data Base for the BOS 
--| Simulator. It provides a complete structure for simulator 
“τ, perameters which can be modified on-line. 


grid_size : constant := 4000; --/| ékm square 

type GRID_TYPE is range 0..grid_size; 

type DEGREES TYPE is digits 6 range 0.0 .. 360.0; --| in circle 
type COUNT_TYPE is range 0..32767; “1 used for most counters 


type INTERVAL_TYPE is new DURATION range 0.001 .. 1000.0; 
τοὶ allowable intervals 
type RATE_TYPE is digits 5; 
--{ used for δίί rate calculations 


ΣΧ Peo wPeverseeeesaceetaversaseetacsetoesetaweeteseenooes 


“- TARGET INFORMATION 5:5 
subtype MAX_TARGETS RANGE is COUNT_TYPE range 1.. 1000; 
“Ὁ RANGE FOR MAXIMUM NUMBER OF TARGETS 


Subtype CREATE_RANGE is INTERVAL_TYPE range 0.1 .. 10.0; 
πὴ. INTERVAL BETWEEN NEW TARGETS 


subtype VELOCITY _TYPE is RATE_TYPE range 0.001 .. 1000.0; 
+>] Allowable velocities in meters/sec. 


Subtype VELOCITY _CHANGE_RANGE is INTERVAL_TYPE range 0.1 .. 60.0; 
>| INTERVAL BETWEEN CHANGES IM TARGET VELOCITY 


subtype TARGET_TURN_RATE_RANGE is RATE_TYPE range 0.01 .. 20.0; 
--[ Valid target turn rates 
type TARGET_MAX_TURN_ANGLE_RANGE TYPE is digits 4 range 0.1 .. 360.0; 
τοῦ degrees 
type TARGET_KILL_RANGE_TYPE is digits 3 range 1.0 .. 100.0; --| meters 
subtype TARGET_TURN_INTERVAL_TYPE is RATE_TYPE range 1.0 .. 1000.0; 


°°] seconds between turns 
type TARGET_CLASS_TYPE fs “:| Supported Target Classifications 
( UNKNOWN, 5.1] Unidentified target 
T80_TANK, +-| Pect Main Battle Tank 
$a_9, στ Mobile SAM 
WMP 2); -<| Armored Personnel Carrier 
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TARGET_PARAMETER_TYPE is record 
MAXIMUM _VELOCITY VELOCITY_TYPE; --| travel in K-meters/hour 
AVERAGE VELOCITY VELOCITY TYPE; --] travel in K-meters/hour 
VELOCITY_CHANGE_INTERVAL : VELOCITY_CHANGE RANGE; --| in seconds 
MAXIMUM_TURN_RATE TARGET_TURN_RATE_RANGE; --| degrees per second 
MAX_TURN_ANGLE TARGET_MAX_TURN_ANGLE_RANGE; --| degrees per turn 
TURN_INTERVAL TARGET_TURN_INTERVAL_RANGE; --| in seconds 


VULNERABILITY RADIUS TARGET_KILL_RANGE; --| meters 
end record; 
MAXIMUM_TARGETS 3 MAX_TARGETS_RANGE := 100; 


--| This value specifies the absolute maximum number of 
κι targets allowed to be actively reported in any one report. 


TARGET_CREATE_INTERVAL : CREATE_RANGE :* create_range’ last; 
+-| Indicates the rate at which targets shall be 
“ Ὁ} generated to achieve the MAX_TARGETS value. 


TARGET_PARAMS is array(TARGET_CLASS_TYPE) of TARGET_PARAMETER_TYPE := 
( UNKNOWN => 


( MAXIMUM_VELOCITY => 100.0 , 
AVERAGE_VELOCITY => 30.0 , 
VELOCITY CHANGE INTERVAL => 5.0 , 
MAXIMUM_TURN_RATE => 20.0 , 
MAX_TURN_ANGLE => 200.0 , 
TURN_INTERVAL => 20 , 
VULNERABILIS‘_RADIUS => 5 

), 

180 ΤΑΝΚ => 

( MAXIMUM ΝΕΙΟΓΙΤῪ => - 9.0, 
AVERAGE _VELOCITY => 50.0 , 
VELOCITY CHANGE_INTERVAL => 10.0 , 
MAXIMUM_TURN_RATE => 30.0 , 
MAX_TURN_ANGLE => 100.0 , 
TURN_INTERVAL => 5.0 , 
VULNERABILITY_RADIUS => 6 

), 

SA_9 => ++ Gaskin Surface to Air Missile Launcher 

( MAXIMUM_VELOCITY => %.0 =, 
AVERAGE_VELOCITY => 67.0 , 
VELOCITY CHANGE_INTERVAL => 30.0 =, 
MAXIMUM_TURN_RATE => 10.0 , 
MAX_TURN_ANGLE => 90.0 , 
TURN_INTERVAL => 1.0, 
VULNERABILITY_RADIUS => 12 

), 

ΒΜΡ 2 5». -- Armored Troop Carrier 

( MAXIMUM_VELOCITY => 59.0 , 
AVERAGE _VELOCITY => 42.0 , 
VELOCITY CHANGE_INTERVAL => 23.0 6 =O, 
MAXIMUM_TURM_RATE => 5.0 , 
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MAX_TURN_ANGLE => 80.0 -, 
TURN_INTERVAL => 23.0 , 
VULNERABILITY_RADIUS => 8 


) 
δ) “55 end of array 


TARGET _CREATE_RATIO is array(TARGET_CLASS_TYPE) of COUNT TYPE := 
(UNKNOWN => 10, T8O_TANK => 50, SA_9 => 20, ΒΜΡ 2 => 20); 
“1 mumbers of each class created per 100 targets 


TARGET_REPORT_INTERVAL : INTERVAL_TYPE :- 0.1; --| seconds per report 


weweesecoe ΟΣ ΧΙ ΚΣ 


“- ROCKET INFORMATION -- 


subtype MAX_ROCKETS RANGE is COUNT_TYPE range 1..100; 
“:] allowable range for number of rockets 


MAXIMUM ROCKETS : MAX_ROCKETS RANGE := 10; --| mumber of active rockets 
type MASS_TYPE is digits 5 range 10.0 .. 100.0; --{ rocket mass 

type THRUST_TYPE is digits 6; --| force in Newtons 

type BURN_RATE_TYPE is digits 5 range 0.001 .. 10.0; --| kg/second 

type RESISTANCE_TYPE is digits 5 range 0.001 .. 100.0; Nsec/m 

type ORIFT_VELOCITY_TYPE is digits 5 renge 0.001 .. 0.5; --{ meters/sec. 


subtype ROCKET TURN_ACCEL_TYPE is mew RATE_TYPE range 0.01 .. 1000.0; 
511 acceleration in degrees per second squared 


type ROCKET PARAMETER _TYPE is record 


MASS s MASS_TYPE := 25.0; --{ kg (no fuel) 
FUEL. s MASS_TYPE : 13.0; --{ kg 
THRUST : THRUST_TYPE := 750; --| Newtons 
BURN_RATE 2 BURN_RATE_TYPE :5 1.0; --| kg/second 
TURN_BURN_RATE : BURN_RATE_TYPE :# 0.2; --| kg/second/degree 
FORWARD_ORAG 3 RESISTANCE_TYPE :π 0.4; --| Newton-seconds/meter 
SIDE_DRAG : RESISTANCE_TYPE := 75.0; --| Newton-seconds/meter 
ORIFT : ORIFT_VELOCITY_TYPE : 0.2; --| meters/second 
TURN_RATE : ROCKET_TURN_ACCEL_TYPE :© 300.0;--| degrees/sec 
LAUNCH_X s GRID_TYPE := grid_size/2.0; 
LAUNCH_Y : GRID_TYPE := 0.0; 
LAUNCH_Z : GRID_TYPE := 0.0; 
LAUNCH_AZIMUTH : DEGREES_TYPE := 90.0; 
LAUNCH ELEVATION : DEGREES_TYPE := 90.0; 

end record; 
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ROCKET : ROCKET_PARAMETER_TYPE; --| hold all rocket parameters 


ROCKET_REPORT_INTERVAL : INTERVAL_TYPE := 0.1;--| interval between reports 


end PDS; --| Parameter Data Base 
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14. Appendix C - Sensor Interface Design Document 


Border Defense System (BDS) 
SENSOR Interface Design Document 
Release 1.0 


14.1 Purpose 


This document describes the interface between the BDS Sensor Subsystem (SS) and the 
Main Control Unit (MCU). All messages are described as well as the general protocol. 


14.2 References 


"The ETHERNET, A Local Area Network Data Link Layer and Physical Link Layer 
Specifications", Version 2.0 1982, Xerox Corporation, Stamford Connecticut. 


14.3 Requirements 
14.3.1 Protocol 


Transmissions will be in accordance with the standard Ethernet Specifications. This applies 
to the Carrier Sense, Multiple Access with Collision Detection CSMA/CD mechanism as 
well as the binary exponential back off technique. Standard Destination and Source Address 
Fields, Length, Type, and Frame Check Sequence (FCS) fields shall be imposed to facilitate 
packet transport. 


14.3.2 Error Recovery 


Error ἐλυμδον will be as follows: Errors shall be detected and logged. Data within an 
incorrect packet shall be discarded, and the previous state of the system shall be 
extrapolated forward in time. Multiple errors may cause performance of the system to 
degrade, including but not limited to loss of target representation and/or accuracy loss in 
rocket guidance. 


14.3.3 Network Address Assignments 


Wetwork Address Assignments: 
Main Control Unit - 02-60-4C-00-00-01 (hexadecimal) 
Sensor Subsystem - 82-60-4C-00-00-02 (hexadecimal) 
Rocket DL Subsystem 5 82-60-4C-00-00-03 (hexadecimal) 


(Note To Facilitate Laboratory Simulation Testing, Sensor Subsystem and Rocket Data Link 
message addresses are "Multi-Cast” addresses and can both be received by a simulator if it is 
configured to receive multi cast addresses.) 

14.3.4 Word Format 


Byte order for data fields after the standard Ethernet header shall be transmitted Least 
significant byte first. 
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Specifically, fields after 'μ5Ο ΓΕΝΟΤΗ" shall be in a format that is directly compatible 
with the 80X86 family byte ordering. For example: 


Number_of Targets - 
Byte Offset 62: Least Significant Byte 
Byte Offset 63: Most Significant Byte 


14.3.5 Message Summary 


Message Name Direction Size (Bytes) Rate 
Target_List SS to MCU 64..862 10Hz Nominal 
Time_Sync_INIT MCU to SS 64 0.01 Hz 


Pee seer cena ereccecccrwes et eweseweesesoacesecessreoseosecce 


14.3.6 Message Descriptions 
14.3.6.1 Target _List Message | 


Direction: Sensor Subsystem = > Main Control Unit 

Size: 64.862 Bytes 

Rate: 10Hz +/-10% 

Description: The Target_J.ist provides updated information on each target in the Area cf Interest 
(AOI). ἀ single ame associated with all reports in the list. Up to 100 target reports may be 
covtained in the list. 
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TARGET LIST MESSAGE “ 
FIELD [SIZE|START | RANGE { UNITS 
| OFFSET | | 
Destination Addr {6 | O | - | 48-bit Net address 
1 | Ι 
Source Addr {6 | 6 Jf - | 48-bit Net address 
If | | 
MSG_Type [2 | 12 { Fixed at S$ {| Integer ID 
1 | Ι | 
MSG_Length }2 4 4% | 64. .862 ] Integer Count 
ΠῚ | | 
Time_Tag }4 | 16 | 0..2*32 | 20.11 usec 
| | 
Spare [42 { 2 ( 7 - 
1 | | 
Ι 


| 

| 

I 
Number_of_Targets| 2 | 62 0..100 | 

ΝΕ Ι 

Ἁλλλλυλλαλαλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλ 
The following fields are provided in accordance with the number 
of targets specified above. 
AAVANAVAAANANANAANANAAAAMAANAMASASAAASAAAAAAAAAAAAAAAN 
Target_Report01 | Ι J Ι 


Target_1001 | 2] 6 0..32767 | Integer [Ὁ 

Target_X POsd! | 2 | 66 0.0..3000.0 | 0.125 meter 
Target_Y_Posoi | 2 | 68 0.0..5000.0 | 0.125 meter 
Target_ClassO1 | 2 | 70 0..3 | Target_Ctass 


{ 

Target_Report02 { 
Target_1002 0..32767 | Integer Id 
Target_X_Pposd2 0.0..3000.0 | 0.125 meter 


I 
| 
I 
{ 
Target_Y_Poso2 | 
Target_Cless02 | 0..3 ] Target_Class 

eee | 

| 

| 

| 

| 


Target_Report_N 
Target_I0_N 


] 
| 
was Ι oss 
| 
2 | 
Target_X POS N | 2 
2 
2 


0..32767 Integer 1D 
0.0..3000.0 | 0.125 meter 
0.0..5000.0 [ 0.125 meter 

0..3 | Target_Cless 


Target_Y_POs_N | 


| 
Ι 
| 
| 
{ 
I 
Ϊ 
| 
| 0,.0..5000.0 | 0.125 meter 
Ι 
| 
| 
| 
| 
| 
l 
{ 
Target_Class_N | { 


© Refer to table in section 3.1 
14.3.6.2 Destination Address 
Refer to Ethernet Specification. 
14.3.6.3 Source Address 
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Refer to Ethernet Specification. 
14.3.6.4 Message Type 

Refer to Ethernet Specification. 
14.3.6.5 Message Length 

Refer to Ethernet Specification. 
14.3.6.6 Time Tag 


This 32 bit value provides a time-of-day in 20.11 microsecond ticks. It will be roll over at 
midnight and reset to zero at that time. This value represents the time at which the sensor 
scan was taken which resulted in the following target list. 


14.3.6.7 Spare 
This field is reserved for future use. 
14.3.6.8 Number of Targets 


This 16 bit value contains the number of targets REPORTED in this message. It ranges 
fro.n 0 to 100. For each target there is a Target Report. 


14.3.6.9 Target Report (N) 


A Target Report consists of: 

16 bit Target ID - a unique number identifying a target. 

16 bit X position - fixed point (‘SMALL of 0.125) indicating 
Χ offset relative to Left most Grid border. 

16 bit Y position - fixed point (‘SMALL of 0.125) indicating 
Y offset relative to Nesrest Grid border. 

16 bit Target Clase - Indicating one of four target 
classifications as follows: 


0 - Unknown 

1 . 780 Battle Tank 

2 - SA-9 "GASKING 

3 - BMP-2 Infantry Combat Vehicle 


Target reports exist for each target being tracked (up to 100). If two consecutive target 
reports arrive with a | oa be! tracked target missing, it is presumed destroyed or masked. 
In either case, the display will no longer indicate existence of the target, and rockets 
on-route will be vectored to the last known position extrapolated according to their last 


known rate. 


14.3.7 Time Synchronize/Initialize 


Demonstration Project Final Report 


Direction: Main Control Unit = > Sensor Subsystem 

Size: 64 Bytes 

Rate: 0.01 Hz 

Description: The Time Synchronize/Initialize message commands the Sensor Subsystem to set 
its clock to the provided value and to begin (or continue) pee target lists. All time tags 
received after transmission of this message shall be time-tagged with respect to this new time. 


TIME SYNCHRONIZE/INITIALIZE MESSAGE 


FIELD |SIZE|START | RANGE | UNITS 
|‘ Jorrset] | 

Destination Addr [6 | O { . | 48-bit Net address 
1 | | | 

Source Addr 16 | 6 | * | 48-bit Net address 
1 | Ι 

MSG_Type , 12] 12 | Fixed at 4 | Integer 10 
ΙΓ! | | 

MSG_Length [2 [| 4% | 64 | Integer Count 
i | | | 

Time_Tag 14 | 16 | 0..20932 { 20.11 usec 


14.3.7.1 Destination Address 
Refer to Ethernet Specification. 
14.3.7.2 Source Address 

Refer to Ethernet Specification. 
14.3.7.3 Message Type 

Refer to Ethernet Specification. 
14.3.7.4 Message Length 

Refer to Ethernet Specification. 
14.3.7.5 Spare 

This field is reserved for future use. 
14.3.7.6 Time Tag 


This 32 bit value contains the current time in 20.11 microsecond increments. Zero (0) refers 
to midnight Universal Time (UT). 
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15. Appendix D - Rocket Data Link Interface Design Document 


Border Defense System (BDS) 
ROCKET Data Link Interface Design Document 
Release 1.0 


15.1 Purpose 


This document describes the interface between the BDS Rocket Data Link (RDL) and the 
Main Control Unit (MCU). All messages are described as well as the general protocol. 


15.2 References 


"The ETHERNET, A Local Area Network Data Link Layer and Physical Link Layer 
Specifications", Version 2.0 1982, Xerox Corporation, Stamford Connecticut. 


15.3 Requirements 
15.3.1 Protocol Transmissions 


Protocol Transmissions will be in accordance with the standard Ethernet Specifications. 
This applies to the Carrier Sense, Multiple Access with Collision Detection CSMA/CD 
mechanism as well as the binary exponential back off technique. Standard Destination and 
Source Address Fields, Length, Type, and Frame Check Sequence (FCS) fields shall be 
imposed to facilitate packet transport. 


15.3.2. Error Recovery 


Error recovery will be as follows: Errors shall be detected and logged. Data within an 
incorrect packet shall be discarded, and the previous state of the system shall be 
extrapolated forward in time. Multiple errors may cause performance of the system to 
degrade, including but.not limited to loss of target representation and/or accuracy loss in 

rocket guidance. 


15.3.3 Network Address Assignments 


Network Address Assignments: 
Main Control Unit - 02-60-4C-00-00-01 (hexadecimal) 
Sensor Subsystem - 82-60-4C-00-00-02 (hexadecimal) 
Rocket OL Subsystem = 82-60-4C-00-00-03 (hexadecimal) 


(Note To Facilitate Laboratory Simulation Testing, Sensor Subsystem and Rocket DL 
mee he message addresses are "Multi-Cast" addresses and can both be received by a 
simulator if it is configured to receive multi cast addresses.) 

15.3.4 Word Format 


Byte order for data fields after the standard Ethernet header shall be transmitted Least 
significant byte first. 
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Specifically, fields after "MSG_LENGTH"’shall be in a format that is directly compatible 
with the 80X86 family byte ordering. For example: 
Number οὐ Rockets - 
Byte Offset 62: Least Significant Byte 


Byte Offset 63: Most Significant Byte 


15.3.5 Message Summary 


Message Name Direction Size (Bytes) Rate 
Rocket_Report_List ROL to MCU 64. .302 10Hz Nominal 
Rocket_Guidance List MCU to δι 64. .862 10Hz Nominal 
Time_Syne_INiT MCU to ROL a 0.01 Hz 


OOOO OOOOH OOOH OSES SESEHAESSEASSHE SHOT ESOS AES HESS SBOSCZES 


15.3.6 Message Descriptions 
15.3.6.1 Rocket_Report_List 


Direction: Rocket Data Link = > Main Control Unit 
Size: 64.302 Bytes 
Rate: 10Hz +/-10% 
Description: The Rocket_Report_List provides updated information on each 
rocket in flight. A separate time-tag is associated with each report in the 
list. Up to 20 rocket reports may be contained in the list. The Rocket Data 
Link subsystem receives messages from the rockets asynchronously over the 100ms 
pa combines all of the reports into a single message for the Main 
ontrol Unit. 


NOTE: The Target Report Fields in the following message are encrypted. 


ROCKET REPORT LIST MESSAGE 


_FIELO |SIZE|START | RANGE | UNITS 
{ {OFFSET | | 

Destination Addr | 6 | O | 3 | 48-bit Net address 
1 Ι Ι 

Source Addr }6 | 6 | με | 48-bit Net eddress 
1 ot | | 

MSG_Type {2 | 12 || Fixed at 2 [ Integer 10 
I of | | 

MSG_Length }2 | % | 64. .862 | Integer Count 
| | | | 

Spare [46 | 16 | - | - 
; | | 

Menber_of Rockets| 2 | 62 | 0..20 | Integer Count 


{ of Ι I 
NANANANANNANAAAVANAAA RAMANA 
The following fields are provided in accordance with the number 
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of rockets specified sbove. 
αλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλλυλλλλλλλλλλλ 


i ἱ Ι 

Rocket_Reporto! | 
Time_Tag01 Ι 
Rocket_1001 | 


b 0..2**32 | 20.11 usec 
2 
Rocket_x_Poso1 | 2 
2 
2 


0..32767 | Integer ID 
0.0..3000.0 | 0.125 meter 
0.0..3000.0 | 0.125 meter 
0.0..3000.0 | 0.125 meter 


Rocket_Y_PosO? | 
Rocket_2_P0S01 | 
| 
J 


Ι 
l 
| 
| 
] 
| 
| 
Rocket_Report02 J 
J 0..2. 412 | 20.11 usec 
| 
J 
| 
| 
\ 
| 
| 
| 
Ι 


Time_Tag02 4} Τὸ 

Rocket_1D02 2) 80 0..32767 =| Integer 10 
Rocket_X_Pos02 | 2 | 8&2 0.0..3000.0 | 0.125 meter 
Rocket_Y_Posd2 | 2] & 0.0..3000.0 | 0.125 meter 
Βοοκοῖ 2 Poso2 | 2 | 86 0.0..3000.0 | 0.125 meter 


Rocket_Report_N 
Time_Tag N 4 |i2ne52; 0..25522 || 20.11 usec 
Rocket _10_N 2 | 12N+56} 9..32767 ἰ Integer ID 
Rocket X POS.N | 2 [12νΝ 958] 0.0..3000.0 [ 0.125 meter 
Rocket f POS_N | 2 [12u*60{ 9.0..3000.0 { 0.125 meter 
Rocket_2 POS.N | 2 [12N+62{ 0.0..3000.0 | 0.125 meter 


SMe emwareesosasestensanvesse Cr er rr errr err 


x 
ee cee ee ee ee ee ee 


* Refer to table in section 3.1 
15.3.6.2 Destination Address 
Refer to Ethernet Specification. 
15.3.6.3 Source Address 

Refer to Ethernet Specification. 
15.3.6.4 Message Type 

Refer to Ethernet Specification. 
15.3.6.5 Message Length 

Refer to Ethernet Specification. 
15.3.6.6 Spare 

This field is reserved for future use. 


15.3.6.7 Number of Rockets 
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This 16 bit value contains the number of fockets REPORTED in this message. It ranges 
from 0 to 20. For each rocket there is a Rocket Report. 


15.3.6.8 Rocket Report (N) 


A Rocket Report consists of: 
32 bit Time Tag - Time the Rocket reported its position. 
16 bit Rocket 1D - a unique number identifying a Rocket. 
. 16 bit X position - fixed point (‘SMALL of 0.125) indicating 
X offset relative to Left most Grid border. 
16 bit Y position - fixed point ('SMALL of 0.125) indicating 
Y offset relative to Nesrest Grid border. 
16 bit 2 position - fixed point (’SMALL of 0.125) indicating 
2 offset relative to Ground Level. 


Rocket reports exist for each rocket in flight (up to 20). If two consecutive rocket reports 
arrive with a previously reported rocket missing, it is presumed to have terminated flight. In 
this case the display will no jongse indicate existence of the rocket, and no rocket guidance 
messages will be generated for that rocket. 


15.3.7 Rocket_Guidance_List 


Direction: Main Control Unit = > Rocket Data Link 

Size: 64.302 Bytes 

Rate: 10Hz+/-10% | 

Description: The Rocket Guidance List provides updated direction information 
for each rocket in flight. The new direction is to be applied immediately by 

the receiving rocket. Up to 20 rocket guidance messages may be contained in 
the list. The Rocket Data Link subsystem will simultaneously transmit all 
messages to the rockets. 


ROCKET GUIDANCE LIST MESSAGE 


FIELO (SIZE(START { RANGE { UntTs 
| [OFFSET | | 
Destination Addr {6 | O | 7 | 48-bit Net address 
I | | | 
Source Addr 16 | 6 f{ 3 { 48-bit Net address 
1 4 | | 
MSG_Type ,2 | 12 | Fixed at 3 | Integer ID 
i ot | | 
MSG_Length 121 % | 66. 862 | Integer Count 
1 4 | | 
Spere } 4} 16 | - Ι 5 
Ι Ι | | 
Wumber_of Rockets| 2 { 62 {| 9..20 | Integer Count 
| 


| | | 
AANANAAAAAAAAANAAAAU AAA AUAAAAN 
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The following fields are provided in accordance with the number 
of reckets specified above. 
NAAAAAALANAAAAAAAARAAAAA AAA 


1 of | Ι 
Rocket_Report0 


1 4 
Rocket_1D01 { 2] 68 | 0..32767 | Integer ID 
Rocket_Azim01 | 2 | 70 | -32768..32767 | BAM 
Rocket_ElevO? | 2 | 72 | -32768..32767 [ 8AM 
it | | 
Rocket_Report02 | | | | 
Rocket_1002 Ι 2[{ 7% | 0..32767 || Integer 10 
Rocket_Azim02 | 2 | 76 | -32768..32767 | BAM 
Rocket_ElevO2 | 2 | 68 | -32768..32767 | BAM 
Ι Ι | 
| -- | - | wate | ee 
J -- | -oe | as | tie 
ἣν epee | ....} ὃ ] e's 
1 Ι | I 
Rocket_Report_N | | | Ι 
Rocket_ID_N Ι 2 | 6n+62] 0..32757 | Integer ID 
Rocket_Azim_N | 2 | 6N+64| -32768..32767 | BAM 
Rocket_Elev_.N | 2 | 6N+66| -32768..32767 | BAM 


BOO On we eee ee Heme O TEE re BST SOS ees eeSEZesnresraseeeserrerteoasecees 


* Refer to table in section 3.1 
13.3.7.1 Destination Address 
Refer to Ethernet Specification. 
15.3.7.2 Source Address 
Refer to Ethernet Specification. 

_15.3.7.3 Message Type 
Refer to Ethernet Specification. 
15.3.7.4 Message Length 
Refer to Ethernet Specification. 
15.3.7.5 Spare 
This field is reserved for future use. 
15.3.7.6 Number of Rockets 


This 16 bit value contains the number of rockets GUIDED in this message. It ranges from 0 
to 20. For each rocket there is a Rocket Direction. 


15.3.7.7 Rocket Direction (N) 
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΄ 


A Rocket Direction consists of: 

16 bit Rocket ID - @ unique number identifying a Rocket. 

16 bit Azimuth - Angle in Binary Angle Measurements with 
respect to the Y axis. (58 = 1/32768 degrees. 
Positive direction is rotation clockwise 
ebout the Z axis. 

16 bit Elevation - Angle in Binary Angle Measurements with 
respect to the Y axis. LSB = 1/32768 degrees. 
Positive direction is rotation up, about 
the X axis. 


15.3.8 Time Synchronize /Initialize 


Direction: Main Control Unit = > Rocket Data Link 

Size: 64 Bytes 

Rate: 0.01 Hz 

Description: The Time Synchronize /Initialize message commands the Rocket Data 
Link to broadcast the time to all ground based rocket launchers. These units 

will set their clocks to the provided value. Just prior to launch, rockets 

will be given this time, and therefore time-tags within rocket messages will be 

with respect to the new time. 


TIME SYNCHRONIZE/INITIALIZE MESSAGE 


FIELD |SIZE|START | RANGE | UNITS 
ἰ {OFFSET | Ι 
ΕΣ ΧΥΧΧΧΧΧΧΧΧΧΧΧΧΧΧΧ Powovertsacvseceeuaseasace 
Destination Addr | 6 |  [ - | 48-bit Net address 
I | Ι | 
Source Addr 16 |] 6 |{ * | 48-bit Net address 
1 | | Ι 
MSG_Type ]2 | 12 | Fixed at 0 | Integer ID 
1 I Ι | 
MSG_Length {2 [| 4 | 64 { Integer Count 
1 | | | 
Time_Tag 14 | 16 [| 0..2*°32 | 20.11 usec 


15.3.8.1 Destination Address 
Refer to Ethernet Specification. 
15.3.8.2 Source Address 

Refer to Ethernet Specification. 
15.3.8.3 Message Type 

Refer to Ethernet Specification. 
15.3.8.4 Message Length 
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Refer to Ethernet Specification. 
15.3.8.5 Spare 

This field is reserved for future use. 
15.3.8.6 Time Tag 


This 32 bit value contains the current time in 20.11 microsecond increments. Zero (0) refers 
to midnight Universal Time (UT). 
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16. Appendix E - Specification for the BDS Test Simulator 
16.1 Scope 


This document, in Sones with the Rocket Data Link Interface Design Document 
(IDD), Sensor Data Link IDD, and the Parameter Data Base (PDB), specifies the 
requirements for the BDS Simulator system. 

16.2 Applicable Documents 

Reference Manual for the Ada Programming Language (ANSI /MIL-STD-1815A-1983) 

Defense System Software Development (MIL-STD-2167- 1985) 

Rocket Data Link Interface Design Document 

Sensor Data Link Interface Design Document 

Parameter Data sass for the 80S Simulator 

16.3 Requirements 

The Simulator for the BDS system poe simulated inputs and outputs for the BDS 
Sensor and Rocket Interface Units. It serves to allow complete testing of the BDS in the 
laboratory. 

16.3.1 Sensor Simulation 

16.3.1.1 Target Data in Parameter Data Base 


The BDS Simulator shall generate simulated sensor data in accordance with the values 
specified in the Parameter Data Base. These parameters shall be interpreted as follows: 


16.3.1.1.1 MAXIMUM_TARGETS 


This value specifies the ab.olute maximum number of targets allowed to be actively reported 
in any one report. 


16.3.1.1.22 TARGET_CREATE_INTERVAL 


Indicates the interval at which targets shall be generated to achieve the MAX_TARGETS 
value. 


16.3.1.1.3 TARGET_CHARACTERISTICS 
Provides the characteristics of each target class. 
16.3.1.1.3.1 MAXIMUM_VELOCITY 


Maximum vehicle velocity. 
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16.3.1.13.2 AVERAGE VELOCITY 

Average vehicle velocity. 

16.3.1.13.3 WELOCITY_CHANGE INTERVAL 
Interval between target velocity changes. 

16.3.1.1.3.4 MAXIMUM_TURN_RATE (angular velocity) 
The maximum rate at which a vehicle can turn. 

16.3.1.1.3.5 TURN_INTERVAL 

The interval at which a new direction is taken. 

16.3.1.1.3.6 MAX_TURN_ANGLE 

Maximum turn angle for any single turn. 

16.3.1.1.3.7 VULNERABILITY_RADIUS 

The radius about the vehicle center that will result in destruction if a rocket strikes. 
16.3.1 1.4 TARGET REPORT _INTERVAL 

Frequency of new target report messages. 

16.3.1.2 Target Creation 


Heke creation shall occur at the TARGET CREATE INTERVAL until the 
i MUM_TARGETS count has been achieved. Thereafter, targets will be created at 
this rate to maintain destroyed ae Targets shall be created in the ratio of target classes 
specified in the PDB TARGET_CLASS RATIO values. Target starting positions shall be 
initialized according to random coordinates between zero(0) διὰ the 
MAXIMUM_START_X and MAXIMUM_START_Y values in the PDB. Targets are 


considered "active" as soon as they are created. 
16.3.1.3 Target Motion 


Target motion will be simulated using random numbers to provide actual motions within the 
maximums specified in the PDB. "Random" values shall have a normal distribution within 
0.3 times the standard deviation and a scaled average of 0.5 + /-10% for samples sizes with n 
> 100. The random πῶ period shall be greater than 2" "16. Random numbers will be 
uniform in the range (0,1). 


Target motion shall always be forward (decreasing "Y" grid offset values). Turns made by 
targets shall be made at the TURN RVAL specified in the PDB within -0/+200ms. 
Vehicles wiil change direction at a rate that is a random factor of the MAX_TURN_RATE 
specified in the PDB. For the purposes of this simulation, the vehicle is assumed to achieve 
the maximum turn rate instantaneously. The desired turn angle shali be determined as a 
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random factor of the MAX_TURN_ANGLE, restricted by maintaining forward motion. 
The change in duecnon shall continue until the desired turn angle is reached, or until a new 
turn is initiated. 


Target travel shall be determined by a random factor of the AVERAGE VELOCITY but 

not exceeding the MAXIMUM VELOCITY values specified in the PDB. Target veloci 

ΟΣ Les recomputed at the VELOCITY_CHANGE INTERVAL specified in the PDB wit 
+200ms. 


All target motion computations shall be done with sufficient accuracy so that the resultant 
positions/times are correct within 1 meter. 


16.3.1.4 Target Reports 


penne reports shall be genetatee at the TARGET REPORT _INTERVAL specified in the 
PDB within +/- 2ms. ae reports shall be in the format specified in the Sensor Data 
Link IDD. Target reports shall contain an entry for each of the active targets. Targets shall 
be considered active from the time they are created until they are destroyed or reach a 
coordinate of range that is zero (Y =0). 


16.3.2 Rocket Simulation 
16.3.2.1 Rocket Guidance 


Rocket Guidance Lists will be received from the BDS main control unit in accordance with 
the Rocket Data Link IDD. All rocket motions shall be simulated with respect to the time 
at which the Guidance Lists are received. If new rocket ID’s appear in the list,.the simulator 
shall initiate a launch for each of the new ID’s. Initial rocket coordinates and vectors for 
launch shall be taken from the PDB parameters LAUNCH_X, LAUNCH_Y, LAUNCH _Z, 
LAUNCH_AZIMUTH, and LAUNCH ELEVATION. 


16.3.2.2 Rocket Report Lists 

Rocket race Lists shall be generated at the rate specified in the PDB value 
ROCKET REPORT_RATE -0/+3ms. Report Lists shall contain the current simulated 
position of each of the active rockets. Rockets shall be considered active after receipt of a 
new rocket ID in a rocket guidance list until the rocket reaches a zero (0) relative altitude 
(Z coordinate = 0) after flight of at least 2 seconds. ; 

16.3.2.3 Rocket Termination 


Rocket Termination shall cause a simulated detonation which will destroy any simulated 
targets that are within their respective vulnerable radius. 


16.3.2.4 Rocket Data in Parameter Data Base 


The BDS Simulator shall generate simulated rocket data in accordance with the values 
specified in the Parameter Data Base. These parameters shall be interpreted as follows: 


16.3.2.4.1 MAXIMUM_ROCKETS 
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Contaias the maximum number of active rockets. Any new rocket ID’s that arrive in 
guidance messages which would result in exceeding this value shall result in an error 
message on the operator display. Such requests for launch will be ignored. 

16.3.2.4.2 ROCKET CHARACTERISTICS 

16.3.2.4.2.1 ROCKET _MASS 

Take off weight of the rocket (in kg). 

16.3.2.4.2.2 ROCKET FUEL 

Amount of rocket propellant (in kg). 

16.3.2.4.23 ROCKET THRUST 

Force of rocket engine (in Newtons). 

16.3.2.4.2.4 BURN_RATE 

Rate at which propellant is consumed (in kg) for forward thrust. 


16.3.2.4.2.5 TURN_BURN_ RATE 


ee τ which additional propellant is consumed for each degree of rotation/second-squared 
effecied. 


16.3.2.4.2.6 FORWARD_DRAG 

Reactive force of air resistance to forward velocity. 

16.3.2.4.2.7 SIDE DRAG 

Reactive force of air resistance to sideslip velocity. Note that the rocket is nearly 
symmetrical about its center line axis, and therefore side drag is independent of which side is 
traveling into the air resistance. 

16 3.2.4.2.8 DRIFT 


hoe motion due to wind (m/sec). This is a maximum value to be modified by a random 
actor. 


16.3.2.4.2.9 ROCKET _TURN_RATE 

It is the maximum acceleration the rocket can achieve. For simplification, the vectored 
thrust for turning can be considered to have no effect on the forward thrust (that is, 
additional fuel is used for turning.) This fuel is burned at the rate of the 
TURN_BURN_RATE value. 


16.3.2.4.2.10 Launch Data 
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LAUNCH_X, LAUNCH_Y, LAUNCH_Z, LAUNCH_AZIMUTH, and 
LAUNCH ELEVATION provide the attitude and position of the rocket at launch. 
16.3.2.4.3 ROCKET REPORT RATE 


The rate at which rocket position report lists are transmitted to the BDS main control unit. 
16.3.2.5 Rocket Motion 


Rocket motion shall be computed at least as frequently as required by the 

ROCKET _REPORT INTERVAL. Rocket motion shall compensate for drag, angular 

acceleration rates, gravity, changes in rocket mass and other drift due to wind. When the 

Ἐπ Ρε παι has been expended and the rocket is still in flight, it shall continue to travel at the 
eading it was at when the fuel ran out. 


All rocket motion computations shall be done with sufficient accuracy so that the resultant 
positions/times are correct within 1 meter. 


16.3.3 Parameter Data Base On-Line Update 


Data Base changes shall occur in a consistent fashion. a paar all parameters for a 
single rocket or sensor list operation will be static. This implies that a synchronization of the 
data base update with access from either the rocket simulation or sensor simulation must be 


performed. 


Values in the PDB will be changed in accordance to the Operator Interface Requirements 
section of this document. 


16.3.4 Scenario Generation/Playback 


‘The BDS Simulator shall have the capability to process a previously generated target 
movement scenario rather than using random motions. An off-line tool shall be provided to 
assist in producing scenarios, and to allow selection of a particular scenario for execution. 
The scenario shall support a sufficient number of targets and target positions so as to 
efficiently utilize up to 256KB of simulator memory. 


16.3.5 Time Synchronization 

16.3.5.1 Sensor Subsystem 

The Sensor Subsystem shall accept a Time Synchronize/Initialize command and set its 
internal time reference accordingly. This internal reference shall be used to supply time tags 
on messages and perform ail time related computations. 

16.3.5.2 Rocket Data Link 

The Rocket Data Link shall accept a Time Synchronize/Initialize command and set its 


internal time reference accordingly. This internal reference shall be used to supply time tags 
on messages and perform all time related computations. 
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It is anticipated that time synchronization will be required within 100us to achieve the 
specified accuracies. 


16.3.6 Operator Interface 
16.3.6.1 Operator Display 


The Operator Display shall indicate current status of the simulation as well as issue 
command prompts and echo operator inputs. The displayed data shall be updated at 
intervals not to exceed 1 second. Simulation data shall consist of a least the following items: 


# of targets active/total 

# of rockets ective/total 

# of destroyed targets 

# of rocket aisses 

# of targets reaching coordinate “Y=0" 


Latest Error Status 


The format of the displayed data shall be proposed by the contractor and will require 
approval of the contracting agency. 


16.3.6.2 Operator inputs 


Ope: uiur inputs shall be menu oriented. All operator inputs shall be checked for validity, 
and errors will allow the operator to reenter the data. At any time, the operator shall be 
able to enter an <ESCAPE> (ASCII 27) characier to return to the tov level menu. 


16.3.6.3 Parameter Data Base Variables 


All Parameter Data Base variables shall be accessible to display and/or modify via the 
operator interface. Allowable ranges for variables shall be displayed in the data entry 
prompts. 


16.3.7 Built In Test 


Built In Test shall be performed with sufficient frequency to detect a stable hardware fault 
in the Encryption unit within 1 second. Such faults will be indicated on the Operator 
Display and invoke an automatic degraded mode of operation using software encryption. 
This degraded mode will reduce the number of active targets to a maximum of 10, and the 
number of active rockets to 1. All rockets in flight in excess of the degraded mode maximum 
during initiation of degraded mode will continue to be tracked. However no guidance 
messages will be processed and no target reports generated for these rockets. 


16.4 Quality Assurance Requirements 
16.4.1 Software Development 
All software shall be developed in accordance with MIL-STD-2167. Designs shall be 


reviewed prior to proceeding with implementation. Code walk throughs shall be conducted 
on all software to insure proper desigr, style, and performance objectives. 
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16.4.2 Test Procedures i 

Test procedures will be written so that testing can be conducted in an automatic fashion to 
the greatest extent possible. Testing shall conducted on all requae ments to insure 
compliance with this specification and any lower level specifications (SDDD in particular). 
16.4.3 Error Budgets 


Error budgets for all timing and calculations shall be documented to indicate where 
allowable errors may occur. 


16.4.4 Programming Language 


The only programming language shall be Ada. No code statements shall be used without 
prior approval of the contracting agency. No assembly statements shall be used. 


16.4.5 Implementation Dependent Features 


Implementation dependent features shall be limited to the greatest extent possible. 
Consideration for transporting the software to a new RunTime Environment will be made 
when evaluating different techniques in implementation. 
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17, Appendix F - Ada Style Guide 

Version 2.1 
17.1 Introduction 
This document was developed to provide guidance in the consistent generation of Ada 
software. If used properly, the effect should be to minimize the likelihood of coding errors, 
improve the readability of the code, simplify the work involved in making minor alterations 
to tie code, and facilitate documentation development. Transportability and reusability are 
addressed through careful use of language features. 
17.2 Identifiers 
The following statements describe the standards that will apply to identifiers: 
. All Reserved word identifiers will be in lower case. 
. All type and subtype identifiers will be in upper case, and will have the suffix " TYPE". 
. All variable identifiers will be in upper case. 
. All enumeration literals will be in upper case. 


. Ail access variables will have the suffix " PTR". 


Rn A & WY N "» 


. All constant identifiers will be in lower case. 


7. All other identifiers will have their first character in upper case with their remaining 
characters in lower case. For names containing embedded underscores, the first character 
after each underscore should be in upper case. Exceptions will be made for common 
acronyms such as "IO", they will appear in upper case: "Text_IO". 


17.3 Identification, Alignment, and Spacing 
The following conventions should be used: 
1. Standard indentation will be two (2) spaces. 
Example: 
if ROCKET_IN_FLIGHT then -- Rocket is atready airborne 
Enable (TRACKER); 
else 


Calibrate (SENSOR); 
end if; 


2. Multiple conditions in an “if...” clause should be grouped together, placed on appropriate 
lines, and aligned so as to enhance clarity. 
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Example: 
if COPERATOR_COMMAND 3 LAUNCH) or 
(TARGET_SELECTED amd AUTOMATIC_MODE) then 
Launch Rocket; 
end if; 


3. Each statement will be on a different line. 
4. The reserved words "begin", "exception", and "end", when used in a subpro 
specification, should be aligned. The code within these reserved words should be indented 


two spaces. 


5. Loop initiators and loop terminators should be aligned. The body of the loop should be 
indented two spaces: 


Example: 
loop 
RESULT := Attempt_Alignment; 
exit when RESULT = GOOD; 
end loop; 


6. A blank space will precede and follow each operator except for exponentiation or 
negation. 


17.4 Comments 


1. A comment header will be placed at the beginning of each subprogram, package, task, or 
generic unit. The PDL templates should be adequate which contain: | 


τι Effects: Describes overall effect of this code section 
--[ Modifies States what global objects are modified directly 
--| Requires Indicates what initialization is required prior to invocation 
+-] Raises Declares what exceptions are potentially explicitly raised and 
propagated from the subprograms 
--{| 9000 Lists what Software Detailed Design Document requirements 
ere fulfilled by this code section. 
στ Engineer Provides the principle designer/coder. 
+-{ Classification (for classified projects only) Indicates security 
requirements for this code section. Appropriate responses are: 
TOP_SECRET, SECRET, CONFIDENTIAL, UNCLASSIFIED_SENSITIVE, 
or UNCLASSIFIED 
The "SENSITIVE" designation applies to information that is 
ITAR Restricted, Export Controlled, Proprietary, or otherwise 
available on 8 “need-to-know" only basis. 


Other standard keywords may be added to the template on a project basis. 


«68- 


Demonstration Project Final Report 


2. An Else statement should always have an embedded comment associated with it. 


Example: 
if ERROR then 
Cancel (LAUNCH); 
else τ ΡΟ error 
Fire (ROCKET); 
end if; 


3. A comment line will be used to describe a relatively long set of related statements 
requiring special attention. 


4. A blank line should proceed and follow each comment line, except for those comment 
lines that make up header blocks. 


5. The use of embedded comments is encouraged. However, care should be taken not ‘o 
obscure the code. 


6. The beginning of each rendezvous statement (possibly compound) will be clearly 
identified with a comment consisting of a full line of dollar signs. 


17.5 PDL Compatibility 


The : ')L will be expanded to produce the operational code. Therefore, there must be a way 
to separate the "high level” constructs from the low level code. A mechanism for this is 
supported by the PDL marker, which consists of pals at the end of an Ada statement. Ada 
code statements which should be included in the PDL listing should have this marker. Note 
that this marker should only appear in non-declarative regions. 


17.6 Restrictions 


1. The use of exception handlers to process errors from predefined exceptions that are 
“known to be possible and can reasonably expected (i.e. hardware faults) is prohibited. They 
should only be used to respond to unexpected errors that are the result of software design 
problems or exceptions that are explicitly "raised". In this way, it may be possible to 
eliminate all runtime checking by using the suppress pragma if the implementation is 
sufficiently trustworthy. 


2. "USE" clauses, in general, are allowed only for Language defined packages. (Those that 
appear in the Reference Manual). In cases where a large number of package-defined 
operators are used, then the "use" clause may be utilized ONLY for convenience of 
reference to operators. Other objects in packages must be referenced via the fully expanded 
name, or by using a "renames" statement or a subtype declaration. Objects referenced from 
ancestor units will use fully expanded names as well. 


3. Use of Generics must be ead approved by the Software Manager. This is primarily 
to coordinate their use, rather than to discourage using generics. 
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4. Records with Default Discriminants are prohibited unless explicitly approved by the 
Software Manager. A statement indicating the performance and size impact of these 
structures should be included in the approval request. 


5. Subprograms are limited to no more than 100 lines of code (semicolons). Compilation 
units should be limited to less than 500 lines of code. 


6. Overloading of names (including operators) is limited to cases where the functionality is 
very similar, otherwise names will not be overloaded. 


7. Package Specifications and Bodies will be separately compiled. Specifications will have 
the suffix "_S" on file names; bodies, including subunits will have the suffix "_B". 


8. References to global data should be restricted to the extent possible. That is, whenever it 
is feasible subprograms should only operate on parameters. For efficiency reasons, global 
data may be accessed when necessary. This must ALWAYS be documented in the 
subprogram header. In cases where the same set of parameters are closely related it may be 
appropriate to combine them into a record type, and pass the entire record as a single 
parameter. Be cautioned to the fact that overhead associated with subprogram invocation 
can be substantial. 


9. The use of tasks must be coordinated. Therefore task declarations are prohibited without 
explicit approval of the Software manager. 


10: Use of the "GOTO" statement is prohibited unless explicitly approved by the Software 
anager. 


11. Units that contain subunits (i.e. parent units) should be limited to structural code that 
primarily invokes the subunits. This technique reduces the number of changes in the parent 
unit, and therefore recompilation of all of the subunits. It also keeps the parent unit at a 
high level relative to that of the subunits which improves comprehension of the resulting 
code. 


12. Subprogram calls should use named parameter association in general. For example: 
PLOT ( POSITION «4» TARGET XY, COLOR => RED ); 


When many parameters are specified, they should be listed one parameter to a line, and 
aligned under the first parameter. For frequently used calls (or language defined 
subprograms) it is unnecessary to used named association. Care should be used to make the 
names appear meaningful and not provide redundant information. 


13. Predefined numeric types should not be usec directly. All numeric types should be 
derived from the Universal types. 


14. Numeric literals other than 0 or 1, shall not appear outside of declarative regions. (That 


is, be embedded in the executable subprogram bodies.) Even these literals wiil only appear 
if they are used to initialize or increment a counter. 
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΄ 


17.7 Naming Conventions 


Names should be selected to be meaningful to anyone trying to read the code, net just the 
original designer. This implies that it is inap popnate to use abbreviations that are not 
clearly understood. Names should be kept under 20 characters in length when possible, in 
recognition of the fact that very large names can detract from comprehension when it is 
difficult to understand the structure because of clutter caused by huge names. For example: 


ttem Good Poor 
List of targets TARGET_LIST TGTLST 
Message Suffer MSG_BUFFER MSGBF 


Mouse (user interface) Report MOUSE_REPORT RAT_MSG 
Ethernet Communications Driver NET_ORIVER ETHERNET_CORMUNICATIONS DRIVER 


΄ 


A list of appropriate "standard" acronyms and names should be maintained for each project. 
Abbreviations such as MSG for message are acceptable provided they are in (or added to) 
the project list. Consistency should be maintained among all of the developed software for a 
project. 
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18. Appendix G - Sample Timing Budget - 


Border Defense System - Sudgeted Times for Major Processing 


_ Average Time per Required 
Function Iterations Iteration Time 
Name per second (microsec) (microsec) 
Receive Rocket Report List 10 200 2000 
Decode Rocket Report 200 800 160000 
Compute Rocket Attitude 200 2000 400000 
Encode Rocket Update 200 800 160000 
Transmit Rocket Update List 10 200 2000 
Display Rocket Position 200 1200 240000 
Receive Target List 10 200 2000 
Display Target Position 1000 725 1068000 
Receive Mouse Character 175 27 4725 
Update Cursor Position 35 2000 70000 
Process Launch Request 2 500 1000 
Update Statistics Display 1 1000 1000 
TOTAL 1767725 


Notes: 
1) Total time indicates greater than 100% utilization for a single processor. 
2) # of interrupts/second 2 205 


3) Total activities/second = 2040 
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The following listing is an example of a time stamp trace for the Rocket.Control task. It 
indicates that the task operates on an accurate 100ms periodic basis until enough rockets are 
airborne so that it begins missing deadlines (marked with an *). 


+-$TP(0002) Control task start time 229934 Delta = 229934 microseconds 
--$TP(0002) Control task start time 330111 Delta = 100177 microseconds 
--$TP(0002) Control task start time 429700 Delta = 99589 microseconds 

--$TP(0002) Control task start time 530269 Delta = 100549 microseconds 
--$TP(0002) Control task start time 629862 Deltas = 99593 microseconds 

~-$TP(0002) Control task start time 729451 Delta = 99589 microseconds 

--$TP(0002) Control task start time 830020 Delta = 100569 microseconds 
--$TP(0002) Control task start time 929610 Deita = 99589 microseconds 

+-$TP(0002) Control task start time 1029201 Delta = 99592 microseconds 
--$TP(0002) Control task start time 1129767 Delta = 100566 microseconds 
--$TP(0002) Control task start time 1229360 Delta = 99593 microseconds 
--$TP(0002) Control task stert time 1329925 Detta = 100566 microseconds 
--$TP(0002) Control task start time 1429517 Delta = 99592 microseconds 
--$T7P(0002) Control task start time 1529107 Delta = 99590 microseconds 
--$TP(0002) Control task start time 1629676 Delta = 100568 microseconds 
--S$TP(Q002) Control task start time 1729265 Delta = 99589 microseconds 
--$TP(0002) Control task start time 1828859 Delta = 99594 microseconds 
--$TP(0002) Control task start time 1929625 Delta = 100567 microseconds 
--$TP(0002) Control task start time 2029015 Ocita = 99590 microseconds 
--$TP(0002) Control task start time 2129585 Deita = 100570 microseconds 
*°STP60N2) Control task start time 2229175 Delta = 99589 mi--roseconds 
--STP(0002) Control tusk start time 2328766 Delta = $9592 microseconds 
~-$TP(0002) Control tesk start time: 2629333 Detta = 100567 microseconds 
--$TP(0002) Control task start time 2528926 Delta = 99593 microseconds 
--$TP(0002) Control task start time 2628516 Delta = 99590 microseconds 
--$TP(0002) Control task start time 2729083 Delta = 100567 microseconds 
--$TP(0002) Control task start time 2828673 Deltas = 99590 microseconds 
--$TP(0002) Control task start time 2929262 Delta = 100569 microseconds 
--$TP(0062) Control task start time 3028832 Delite = 99589 microseconds 
--3TP(0002) Control task start time 3128422 Delta = 99590 microseconds 
--$1P(0002) Control task start time 3228969 Deita = 100567 microseconds 
--$TP(0002) Control task start time 3328579 Delta = 99590 microseconds 
+-$TP(0002) Control task start time 3428173 Delta = 99594 microseconds 
--$TP(0002) Control task start time 3528760 Delta = 100567 microseconds 
+-$TP(0002) Control task start time 3628331 Delts = 99591 microseconds 
--$TP(0002) Control task start time 3728900 Deits = 100569 microseconds 
--$TP(0002) Control task start time 3828491 Delta = 99591 microseconds 
«-$TP(0002) Control task start time 3928081 Delta = 99590 microseconds 
-°$TP(00U2) Control task start time 4020648 Deita = 100567 microseconds 
--$TP(0002) Controi task start time 4128239 Delta = 99591 microseconds 
--$1P(0002) Control task start time 4227829 Delta = 99590 microseconds 
+-$TP(0002) Control task start time 4329371 Delta = 101542 microseconds 
<-$TP(0002) Control task start time 4427989 Delta = 98617 microseconds 
-°$TP(0002) Control task start time 4528555 Delta = 100567 microseconds 
--$TP(0002) Control task start time 4628146 Delta = 99591 microseconds 
--$1P(0002) Control task start time 4728713 Deita = 100567 microseconds 
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--$TP(0002) 
--$TP¢(0002) 
--$TP(0002) 
--$TP( 0002) 
-°$TP(0002) 
+-$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
°-$TP(0002) 
--$TP(0002) 
-°$TP(0002) 
--$TP¢0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--°$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$STP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
--$TP(0002) 
-+$TP(0002) 
--$TP(0002) 
--$TP(0002) 
-+$TP(0002) 
*-$TP(0002) 
--$TP(0002) 
--$TP(0002) 
+*$TP(0002) Control 
+~$TP(0002) Control 
+°S$TP(0002) Controi 


Control 
Control 
Control 
Control 
Controt 
Control 
Control 
Control 
Control 
Control 
Controt 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Controt 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 
Control 


task 
task 
task 
task 
tesk 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
tesk 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
task 
tesk 


start 
start 
etert 
start 
etert 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
stert 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
start 
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time 
time 


4828306 Delta 
4927896 Delta 
5027487 Delta 
5128054 Delta 
5227645 Delta 
5328273 Delta 
5427802 Delta 
55273% Delta 
5634545 Delta 
5727554 Delta 
5827144 Delta 
5933623 Delta 
6027303 Delta 
6127870 Delta 
6233782 Delta 
6330899 Delta 
64324694 Delta 
6533338 Delta 
6638533 Delta 
6740030 Delta 
6841556 Detta 
7029347 Delta 
7132627 Delta 
7262113 Delta 
7617546 Delta 
7529064 Delta 
7635551 Delta 
7742059 Delta 
7919917 Delta 
8027722 Delta 
8141697 Delta 
8307434 Delta 
8423121 Deita 
8534182 Delta 
8697240 Delta 
8815014 Delta 
8928160 Delta 
9040253 Delta 
9205898 Delta 
9321093 Deita 
9436134 Delta 
9592926 Delta 
9707996 Delta 
9623226 Delta 
9938537 Delta 
10096715 Delta = 
10211935 Deita = 
10327281 Celta = 


Cr re ee κμ"" 


99594 microseconds 
99590 microseconds 
99590 microseconds 
100567 microseconds 
99591 microseconds 
100628 microseconds 
99530 microseconds 
99591 microseconds 
107152 microseconds 
93008 microseconds 
99590 microseconds 
106479 microseconds 
93680 microseconds 
100567 microseconds 
105912 microseconds 
97117 microseconds 
101595 microseconds 
100844 microseconds 
105195 microseconds 
101498 microseconds 
101526 microseconds 
187791 microseconds 
103279 microseconds 
109486 microseconds 
175433 microseconds 
111518 microseconds 


. 106488 microseconds 


106508 microseconds 
177857 microseconds 
107805 microseconds 
113975 microseconds 
165737 microseconds 
118687 microseconds 
111061 microseconds 
163058 microseconds 
117774 microseconds 
113146 microseconds 
112092 microseconds 
165646 microseconds 
115195 microseconds 
115041 microseconds 
156792 microseconds 
115070 microseconds 
115230 microseconds 
115311 microseconds 
158178 microseconds 
115220 microseconds 
115346 microseconds 
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19 Appendix H - Border Defense System Ada Source Code 


The source code for the BDS system follows in alphabetical order 
of the unit names (specifications precede bodies). 
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+>] UNIT: BOS Spec & Body. <2 
--| Effects: Initiates main processing, loops recording idle time. -- 
στ Modifies: No globat data is modified. Ἐν 
--| Requires: Status.Jnitialize be called before Mouse.Initialize. 85 
“:-| Raises: Wo explicitly raised exceptions are propagated. =< 
τι Engineer: T. Griest ᾿Ξ 
+ -teterewernrteners Distribution and Copyright 
+> Derivation : LabTek Sorder Defense System V1.0 


4. 


“- This Border Defense System Software inherits the LabTek copyright. 
στ The following copyright must be included in all software utilizing 
-- this application program. 


-- Copyright 1989 by LabTek Corporation, Woodbridge, CT, USA 


*- Permission to use, copy, modify, and distribute this 

~- softwere and its documentation for any purpose and without 
“. fee is hereby granted, provided that the above copyright 
-- notice appear in all copies and that both that copyright 
*- notice and this permission notice appear in supporting 

+- documentation, and that the name of LabTek ποῖ be used in 
-- advertising or publicity pertaining to distribution of the 
++ software without specific, written prior permission. 

κε LabTek makes no representations about the suitability of 
+- this software for any purpose. It is provided "δὲ is" 

-- without express or implied warranty. 


o*# @ @ ὃ ὃ δ κα ὃ δ ὁ Κὶ ἡ ὁ 8s. © © © κα & 


ΙΝ ΕΟ 
| 
| 


-- This software and its documentation are provided "AS 15" and 
-- without any expressed or implied warranties whatsoever. 

-° No warranties as to performance, merchantability, or fitness 
~- for a perticuler purpose exist. 


** In no event shall amy person or organization of people be 
-- held responsible for any direct, indirect, consequential 
-- or inconsequential damages or lost profits. 


, 
‘ 
* 2, ΚΝ © © © © & @ Ὁ 


with Config; ++ global configuration parameters 

with Status; -- updates statistics used 

with Types; “. global types definitions 

with Mouse; τ. mouse movement end rocket launching 

with Rocket; +> rocket attitude end aimpoint calculations 
with Target; “- generation of various targets 


with Interrupt_Control; -- enabling and disabling of (all) interrupts 
with Mechine Dependent; -- individual pixel plotting for EGA 
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with Time Stamp; -- run time profiler 
pragma ELABORATE(Mouse, Status, Interrupt_Control, Time_Stamp); 


procedure 80S is 

+: This is the main program for the Border Defense System. It has only 

-- two calls which are of any importance, i.e., the other code is for 

“> timing purposes only. The first call performs initialization of t-e screen 
++ statistics descriptions end their initial values. The second call starts 
~- the mouse. 


use Types; -- for visibility to "+" 


pragma PRIORITY(Config.bds_ priority); 


COUNT : Types.WORD; “- these two variables ere for 
SLOW : Types.WORD; “- slowing the time stamps 
begin Ἷ 
Status. Initialize; -- print screen statistics 
Mouse. Initialize; -- must be done after status signal 
Loop -- done with initialization 
--3TP(0001) BOS main time stamp 
SLOW :: 1; 


for COUNT in 1..2000 loop 
SLOW 3: 90 + 1; 
end loa; 
end loop; 
end Ss; 
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ΚΤΎΠΟΝ: Config Spec. 

55: Effects: Provides system-wide configuration constants. 
“τ Modifies: No global data is modified. 

“τ Requires: No initiatization is required. 

o-| Raises: No explicitly raised exceptions are propagated. 
+-| Engineer: T. Griest. 


PMS ee ree taceseesesevesecrersestasenscesasenseress saceovesoce ene 


τ᾿ Date 2 10-11-88 
στ Purpose : 


-- This package contains global configuration parameters. 


Final Report 


It fs referenced 


-- for ALL parameters which are likely to be changed during system maintenance. 


with System: 
package Config {s 


<-> The following two constants allow the space needed for the 
-- be declared in bytes. 
byte 
bytes_per_storage_unit 


constant :5 8; -- 8 bits 


κυ Now define battlefield area perimeters 


various tasks to 


constant :5 byte / System.STORAGE_UNIT; 


meters_in_battle_area : constant : 6000.0; -- in X and Y direction 


meters _per_X_pixel constant 
meters _per_Y_pixel 


max_pixels_in_battle_area 


constant := meters_in_battle area 


:α 9.625; -- rounded up to nearest 
constant :2 11.875; -- Types.METER. 


/ meters_per_X_pixel; 


max_active_symbols 3 constant :5 200; “- max simultaneous symbols 


-- Task priorities in order of decreasing urgency. 


-- NOTE: MOUSE IN_CHAR has no priority because it runs 
-- completely at the hardware interrupt level. 


-- The idea implemented here is thet ell the Simulator information is 
-- of higher priority than the ectusl Border Defense System code. 


save_priority 2 constant :5 20; -- Mouse_Buf 
display_priority 3 constant :" 18; -- Graphics 
treck_date_priority 2 constant : 16; -- Target 
report_buf_priority : constant :5 9; “- Simulator 
gquide_buf_priority 8 constant :5 9; <> Simulator 
rock_sup priority : constant :5 8; -> Simulator 
targ_sup_priority : constant :5 7; o> Simulator 
control _priority : constant :s 5; -- Rocket 
quidance_priority 3 constant :5 4; o> Rocket 
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fer 


track_priority 
update priority 
hds_priority 
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constant 
constant 
constant 


ee 08 ὁ 
" 

=  υὧἱ 

me 8s we 


΄ 


-- Target 
-- Status 
-- Main 


-- define entire hi-res screen display borders. The screen is divided into 

-- two main sections. There is the battlefield area where the targets, rockets, 
-- and reticle are allowed to move, and there is the statistics area where our 
++ current statistics will be displayed. The maximum number of digits allowed 
στ in any statistics displayed is statistics_length. Between the statistics and 
-- the battlefield there is 4 border. 


-- define entire screen constants 


entire_screen_left : constant := 0; 
entire_screen_right 3 constant :3 639; 
enti re_screen_top : constant := 0; 
entire_screen_bottom 3 constant := 349; 


-- define battlefield display borders end center. 


yatttetield_screen_left : constant : 222; -- starting (left) 
vactlefield_screen_right : constant := 638; -- ending (in pixels) 
battlefield _screen_top 2 constant : 1; -- starting (ton) 
battlefield screen _bottua : constant :+ 338; -- anding Cin pixels) 
battlefield center_x : constant := 430; -- 
battlefield_center_y s constant :5 169; 55 


-- define border between battlefield and statistics. 


border_left 2 constant := 221; “τ starting (left) 
border_right : constant :5 639; -- ending (in pixels) 
border_top : constant :2 0; <- starting (top) 
burder_bottom 3 constant :5 339; “τ ending Cin pixels) 


-- define statistics display borders. 


status_left 3 constant :π 0; -- starting (left) 
status_right : constant :5 220; “- ending (in pixels) 
status top : constant :π 0; “- starting (top) 
status bottom : constant :5 349; “- ending (in pixeis) 


+ statistics_length is the number of digits allowed in any status field, and 
“τ stats_title_max_(ength is the max number of letters any particuler 
“- statistics title may contain. 


statistics_length 3 constant := 4; 
stats_title max_length 2 constant := 11; 
max_targets 2 constent := 100; -- total targets 
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max_rockets 
interval 

-+ launch attitude 
launch_azimuth 
launch_elevation 


kill_radius 


end Config; 
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constant 


constant 


constant 


constant 


constant 


20; 


0.100; 


16384 
16384 


10.0; 


we “ὦ 


+> total rockets 


basic interval is 100ms 


straight shead in BAMS 
straight up in BAMS 


-- 10 meters x 10 meters 
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+e] UNIT: Control task subunit. -- 
5: Effects: Provides overall control for rocket flight and display.  “-- 
--| Modifies: Updates rocket data bese in Rocket body. -- 
--| Requires: No initialization is required. -- 
--| Raises: No explicitly raised exceptions are propagated. “- 
--| Engineer: T. Griest. -- 


with Interrupt_Control; 
with Grid_to_Pixel; 
with Simulate; 
with Target; 
with Calendar; 
with Engage; 
with Time Stamp; 
pragma ELABORATE(Interrupt_Control, Grid_to_Pixel, 
Simulate, Target, Calendar, Engage, Time_Stamp); 


separate(Rocket) 

-- The Control task accepts data from the Rocket Data Link, 

στ provides information to the Display task, od disperses information 
to each of the guidance tasks, It then collects the computations 
of the guidance tusks, and generates a qui:iance message to be sent 

το back to the Rocket Oata Link 


task body Control_Type is 


use Calendar; -- for operators 
use Types; -- for operators 


package ROL renames Simulate.ROL; “-- make simulator transparent 


dis_list_size 8 constant :5 Config.max_rockets; 


MOVE _NUMBER 2 Types .WORD_INDEX; 

το. to updete display 
WEXT_ROCKET_MSG : ROCKET_MSG_TYPE; --| local copy of input meg 
NEXT_TARGET_LIST : Target. TARGET_DATA_LIST TYPE; --| local copy of input data 


GUIDE _MSG ROCKET_GUIDE_MSG_TYPE; τῷ local copy of output msg 


AIMPOINT_LIST : AIMPOINT_LIST_TYPE(Types.ROCKET_ INDEX TYPE); 


--| local copy 
WOVE _ROCKETS : Graphics .MOVE_LIST_TYPE( Types .ROCKET_INDEX_TYPE); 
MOVE _INDEX s Types. WORD_INOEX; 
PIXEL_POINS : Shapes.PIXEL; 
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MSG_ INDEX : 
OLD_TIME_TAG : 
ANY_ACTIVE_ROCKETS 
ACTIVE_ROCKETS_10 


WEXT ENGAGED : 
WEXT_DISENGAGED : 


DISENGAGED_LIST : 
DISENGAGED_ON_PTR 

DISENGAGED_OFF_PTR 
DISENGAGED_ACK_PTR 


AVAILABLE_ROCKET : 
LAUNCH PENDING : 
LAUNCH TARGET : 


LAUNCH_ROCKET 


ROCKET DESTROYED 
ROCKET LAUNCHED 


START_TIME 
DELAY_PERIOO 


begin 
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Types. WORD_INOEX; >| ased to index incoming report 
Types .WORD; --| to filter stale reports out 
: BOOLEAN := FALSE; --| used to update OLD_TIME_TAG 
: Types.ROCKET_INOEX_TYPE; --{ holds δὴ active rockets I0 


Target. TARGET_!D_TYPE; 
Target. TARGET_!0_TYPE; +-| keep track of sll disengagements 


array( Types ROCKET _INDEX_TYPE) of Target .TARGET_ID_TYPE; 
: Types.WORD_INOEX; 
: Types.WORD_INDEX; 
: Types .WORD_ INDEX; 


Types .WORD_ INDEX; --| possible rocket to launch 
BOOLEAN :2 FALSE; 
Target. TARGET _ID_TYPE; 


Types .ROCKET_INDEX_TYPE; 


BOOLEAN; 
BOOLEAN; 


Calendar. TIME; 
DURATION; 


for 1 in ROCKET_HISTORY‘range toop --| initialize track data 
ROCKET_HISTORY(1) ACTIVE :5 FALSE; 
DISENGAGED_LIST(I) := 0; 


end loop; 
NEXT_ENGAGED := 0; 


DISENGAGED_ON_PTR 
DISENGAGED_OFF_PTR 
DISENGAGED_ACK_PTR 


OLD_TIME_TAG := 0; 


sz 1; --| initialize disengage circle queue 


START_TIME := Calendar.CLOCK; 


loop 
begin 


--| Main processing loop 
“:| exception block 


START_TIME :5 START_TIME + Contig. interval; 
--$7P(0002) Control task start time 
ROCKET_DESTROYED := FALSE; 


ROCKET _LAUNCHED 


33 FALSE; 


ANY_ACTIVE_ROCKETS := FALSE; 


-- Rendezvous with buffer task to get next rocket message from sensor 


--$7P(0003) Control rendezvous with Report_Buf start 
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ROL .Report_Buf .Get_Report(NEXT_ROCKET_MSG); 
--$TP(0004) Control rendezvous with Report_Buf end 


+- Rendezvous to Get target list from target tracker, and provide it 
+- with information on which targets have been engaged and disengaged. 


-- If there are more on circular disengage queue, send another to tracker 


if DISENGAGED_OFF_PTR /= DISENGAGED_ON_PTR then 
NEXT_DISENGAGED := DISENGAGED_LIS?(DISENGAGED_OFF PTR); 
DISENGAGED_OFF_PTR := DISENGAGED_OFF_PTR rem dis_list_size + 1; 
else 
NEXT_DISENGAGED := 0; 
end if; 


~-$7P(0005) Controi rendezvous with Treck Dat start 

7“ SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSESSSESSSSSSSSSSSSSSSSSSSSSSSISSSS 
Target.Track_Data.Get(NEXT_TARGET_LIST, NEXT_ENGAGED, NEXT_DISENGAGED); 
--$TP(0006) Control rendezvous with Track Dat end 


-- Check if Track task has recognized the engage request, if so then 
-- it is safe to clear it, and possibly engage another. 


if NEXTLENGAGED /= 0 and then 
NEXT_TARGET_LISTCNEXT ENGAGED ) STATUS. ENGAGED 
then 
NEXT_ENGAGED :2 0; 
end if: 


+> Check to see if last disengage request was acknowledged 


if DISENGAGED_ACK_PTR /= DISENGAGED_OFF_PTR and then 

mot NEXT_TARGET_LIST(OISENGAGED_LIST(DISENGAG:D ACK_PTR)).STATUS.ENGAGED 
then 

DISENGAGED_ACK_PTR := DISENGAGED_ACK_PTR rem dis list_size + 1; 
end if; 


το. determine which rockets have been expended, and delete them from screen 
--| (previously active, but no longer in report list) 

MOVE_INDEX := 0; 

MSG_INDEX :" 1; 

for ROCKET_IO in Types.ROCKET_INOEX_TYPE Loop 


if ROCKET_HISTORY(ROCKET_ID).ACTIVE then 
if NEXT_ROCKET_MSG.ROCKET_LIST(MSG_INDEX).TIME_TAG * OLD_TIME_TAG then 
ANY _ACTIVE_ROCKETS := TRUE; 
ACTIVE_ROCKETS_ID := ROCKET_ID; 
exit; -- old rocket report 
end if; 
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-- look at most recent rocket report message to meke sure rocket is still alive 


if MSG_INOEX <s NEXT_ROCKET_MSG.NUM_ROCKETS and then 
ROCKET_ID = NEXT_ROCKET_MSG.ROCKET_LIST(MSG_INDEX) .ROCKET_ID 
then 
ROCKET_HISTORY(ROCKET_1D).POSITION_PAIR.ROCKET_OLD := 
ROCKET_HISTORY(ROCKET_ID).POSITION_PAIR.ROCKET NEW; 
ROCKET _HISTORY(ROCKET_1D).POSITION_PAIR.ROCKET NEW := 
WEXT_ROCKET_MSG.ROCKET_LISTCMSG_INDEX).POSITION; 
ROCKET _HISTORY(ROCKET_1D).POSITION_PAIR.TARGET_OLD :- 
ROCKET_HISTORY (ROCKET_1D).POSITION_PAIR.TARGET_NEW; 
ROCKET _HISTORY (ROCKET_ID) .POSITION_PAIR. TARGET NEW := 
WEXT_TARGET_LISTCROCKET_HISTORY(ROCKET_ID). TARGET) .POSITION_NEW; 
MOVE_INDEX := MOVE_INDEX + 1; 
MOVE, ROCKETS(MOVE_INDEX) :Ξ 
(XY_OLD => Grid_to_Pixel (ROCKET_HISTORY(ROCKET_ID).POSITION_PAIR.ROCKET_OLD), 
XY_NEW => Grid_to_Pixel (ROCKET_HISTORY(ROCKET_ID).POSITION_PAIR.ROCKET_NEW), 
OBJECT => (Shapes.PIXEL_MODE, Shapes.ROCKET), 
COLOR => Graphics.ROCKET_COLOR); 
MSG_INDEX :5 MSG_INOEX + 1; 
else 


s+ the rocket has deceased, put it in the list for erasure. 


PIXEL_POINT := Grid_to_Pixel( => get last point in pixel value 
ROCKET_HISTORY(ROCKET_ID) .POSITION_PAIR.ROCKET_NEW); 
ROCKET_HISTORYCROCKET_ID).ACTIVE := FALSE; -- mark as inactive 
MOVE_INDEX := MOVE_INDEX + 1; 
MOVE _ROCKETS(MOVE_INDEX) :2 
(PIXEL _POINT, 
PIXEL_POINT, 
(Shapes .PIXEL_MODE , Shapes. ROCKET), 
Graphics .beckground_color); 
AVAILABLE ROCKET :5 ROCKET_10; τε save if decide to launch 
OISENGAGED_LIST(OISENGAGED_ON_PTR}:= ROCKET_HISTORY(ROCKET_ID). TARGET; 
OISENGAGED_ON_PTR := DISENGAGED_ON_PTR rem dis_list_size + 1; 
Interrupt_Controt disable; 
Status.STATUS_CONTROL (Status. AIRBORNE) .DATA :5 
Status.STATUS_CONTROL (Status. AIRBORNE) .DATA - 1; 
Status.STATUS_CONTROL (Status.EXPENDED) .DATA :5 
Status.STATUS_CONTROL(Status.EXPENDED).DATA + 1; 
Interrupt_Control .Enable; 
ROCKET _DESTROYED :* TRUE; 
end if; -- found 
else 


-- rocket slot previously inective, see if rocket has launched 
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if MSG_INDEX <= NEXT_ROCKET_MSG.NUM_ROCKETS and then 
NEXT_ROCKET_MSG.ROCKET_LIST(MSG_INDEX).ROCKET_ID = 
ROCKET_ID 
then 


ἘΞ ROCKET HAS BEEN LAUNCHED, UPDATE DATA BASE 


ROCKET_HISTORY(ROCKET_ID) := 
( TRUE, κα ACTIVE 
LAUNCH_TARGET, => TARGET 
( NEXT_ROCKET_MSG.ROCKET_LIST(MSG_INDEX).POSITION, -- NEW 
NEXT_ROCKET_MSG.ROCKET_LIST(HSG_INDEX).POSITION, -- OLD 


NEXT_TARGET LISTCLAUNCH_TARGET).POSITIOW_NEW, -- NEW 
NEXT_TARGET_LISTCLAUNCH TARGET) .POSITION_NEW) -- OLD 
); 
LAUNCH PENDING := FALSE; στ all accounted for 


MSG_INDEX := MSG_INDEX + 1; 

Intérrupt_Control Disable; 

Status.STATUS_CONTROL (Status AIRBORNE) .DATA :5 
Status.STATUS CONTROL (Status. AIRBORNE) .OATA + 1; 

Interrupt_Control .Enable; 

ROCKET _LAUNCHED := TRUE; 


else 
AVAILABLE_ROCKET := ROCKET_IO; 
ed if; ** mew rocket test 
and if; *- active test 
ernd Loop; -- rocket-id loop (scan of all rockets) 


--| Update Time tag for next message. 
if ANY_ACTIVE_ROCKETS then 
OLD _TIME_TAG := NEXT_ROCKET_MSG.ROCKET_LIST(ACTIVE_ROCKETS_ID).TIME_TAG; 
end if; -- if no active rockets, don’t change OLD_TIME_TAG. 


--| Get guidance tusk(s) working on finding new aimpoint for guidance msg 
for { in Types.WORD_INODEX range 1..Distrib.num_guide_tasks loop 
-°$TP(0007) Control rendezvous with Guidance(1) start 
Rocket_Guide(1).History(¢ 
ROCKET_HWISTORY (Distrib. quide_low(!)..Distrib.guide_high(I))); 
--$TP(0008) Control rendezvous with Guidance(1) end 
end loop; 


--| update status information 
Interrupt_Control Disable; 
if ROCKET_LAUNCHED then 
Status. STATUS_CONTROL (Status .AIRBORNE) DISPLAYED := FALSE; 
end if; 
if ROCKET LAUNCHED or ROCKET_DESTROYED then 
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Status .STATUS_CONTROL (Status .AIRBORNE).DISPLAYED := FALSE; 
Status.STATUS_CONTROL (Status EXPENDED) .OISPLAYED := FALSE; 
Status.REQ_COUNT := Status.REQ_COUNT + 1; 
if Status.REQ_COUNT = 1 then 
--$TP(0009) Control rendezvous with Status start 
Status .Update.Signal; 
+-$TP(0010) Control rendezvous with Status end 
end if; 
end if; 
Interrupt_Control .Enable; 


MSG_INDEX := 0; στ zero index for creating guidance message 


-> Now, check if we should try to create a new ROCKET. Note that 
στ if a rocket has just been destroyed, don’t try to fire a new one 
στ before the rocket tracker knows that it has been disengiged. Otherwise 
-- it is likely to choose a target other than one that is closest. 
if mot LAUNCH_PERNOING and 
DISENGAGED_ACK_PTR = DISENGAGED_ON_PTR and -- ail have been ack’ed 
NEXT_ENGAGED = 0 "s+ engage has been ack/ed 
then 
WEXT_ENGAGED :π Engage(NEXT_TARGET_LIST); 
if NEXT_ENGAGED > 0 then 
LAUNCH ROCKET := AVAILABLE_ROCKET; 
LAUNCH_TARGET := NEXT_ENGAGED; 
LAUNCH_PENOING :5 TRUE; 
end if; -- ready to launch 
end if; --+ not pending check 


--| get graphics task working on displaying rockets 
+-$TP(0011) Control rendezvous with Graphics start 
Graphics .Display.Move(Graphics.LOW, MOVE_ROCKETS(1..MOVE_INDEX)); 
--$TP(0012) Control rendezvous with Graphics end 


oe 


το now get results of guidance information 
for { in Types.WORO_INDEX range 1..Distrib.nm_quide tasks loop 
~-$TP(0013) Control rendezvous with Guidence(2) start 
Rocket_Guide(1).Next_Guidance( 
AIMPOINT_LIST(Oistrib. guide_low(!). Distrib. guide high(1)) ): 
--$TP(0014) Control rendezvous with Guidance(2) end 
end loop; 


-- Wow generate new guidance message and send to Guide_Buf 


for ROCKET 10 im ROCKET _HISTORY’RANGE loop 
16 ROCKET _HISTORY(ROCKET_ID).ACTIVE then 
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MSG_INDEX := MSG_INDEX + 1; 
GUIDE_MSG.ROCKET_GUIDE_LIST(MSG_INDEX) := 


(ROCKET_ID, AIMPOINT_LIST(ROCKET_ID)); 


elsif LAUNCH_PENDING and then 
ROCKET_ID = LAUNCH_ROCKET then 
MSG_INDEX := MSG_INDEX + 1; 
τ initiate launch 
GUIDE_MSG.ROCKET_GUIDE_LIST(MSG_INDEX) := (ROCKET_ID, 
(Config. launch_azimuth, 
Config. launch_elevation)); 
end if; 
ere: loop; 
GUIDE_MSG.NUM_ROCKETS := MSG_INOEX; 
--$TP(0015) Control rendezvous with Guide_Buf start 
ROL .Guide_Suf .Put_Guide(GUIDE_MSG); -- send new guidance message 
--$TP(0016) Control rendezvous with Guide_Buf end 


-- periodic schedule 
DELAY PERIOD := START_TIME - Calendar .Clock; 
if DELAY PERIOD < 0.0 then 
START_TIME :2 Calendar .Clock; 
end if; 
--$TP(0017) Control task end time 


delay DELAY PERIOD; 
exception 


when others 3> 
Debug_[0.Put_Linec"Exception in Control task"); 


end; -- exception block 
end loop; το. main processing Loop 
end Control_Type; -- Rocket.Control task body 
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στ} UNIT: Distrib Peckage Spec. “- 
τ Effects: Provides perameters to control task arrays and work lists.-- 
“:] Modifies: No global data is modified. 

Ὁ. Requires: No initialization is required. 

τ Raises: No explicitly raised exceptions are propagated. 

--| Engineer: ΤΊ Griest. 


eet ewewoeacocecce werececcccaas οι στο π 0.555... woweescececcoecces “-....- ΟΣ, 


with types; 


-- DISTRIBUTION CONTROL PARAMETERS 
package Distrib is 
num_guide_tasks constant :Ξ 1; -- for now 
guide (ow constant srray(Types.WORD_INDEX range 1..num_guide_tasks) 
of Types.WORD_ INDEX := (others=>1); 
guide _high constant array(Types.WORD_INOEX range 1..rman_guide_tasks) 
of Types.WORD_INDEX := (others=>20); 
end Distrib; 
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*-| UNIT: Engage Procedure Spec. ἘΞ 
-| Effects: Determines if Rocket is to be launched, and at what target.- 
τ] Modifies: No giobal data is modified. -- 
--| Requires: Status package must set mode and airborne counts. -- 
“- Raises: Wo explicitly raised exceptions are propagated. od 
e-| Engineer: M. Sperry. -- 


-- The ENGAGE procedure determines if a new rocket should be launched, 
το and if so, which one it should be. This is based on the MODE, either 
-- Manual or Automatic, the number of rockets already in flight, and 

-- (when in Manual mode) the LAUNCH button on the operator console. 

-- This routine is called during every rocket control task iteration. 


++ Returned TARGET parameter is ZERO if no target should be engaged, 
-- otherwise it indicates the selected target. 


with Target; 


function Engage(TARGET_INFO : in Target.TARGET_DATA_LIST_TYPE) return 
Target .TARGET_ID_TYPE; 
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| UNIT: Engage Procedure Sody. “» 
| Effects: Determines if Rocket is to be launched, end δὲ what target.- 
| Modifies: No global data is modified. “. 
| Requires: Status package must set mode and airborne counts. 55 
| Raises: No explicitly caised exceptions are propagated. -- 
| Engineer: M. Sperry. bg 


-..-.---..-.. που στ στο σ 55.5.5 .“5.“--.-.... ---... eweceecsccesac=s eeocvosevesaace . 


The ENGAGE procedure determines if a mew rocket should be launched, 
and if so, which one it should be. This is besed on the MODE, either 
Manual or Automatic, the number of rockets already in flight, end 
(when in Manual mode) the LAUNCH button on the operator console. 

This routine is called during every rocket controi task iteration. 


Returned TARGET parameter is ZERO if no target should be engaged, 
otherwise it indicates the selected target. 


th Interrupt_Control; 
th Status; 
th Mouse Buffer; 
th Types; 
th Config; 
th Shapes; 
th Time_Stamp; 
pragma ELABORATE(Interrupt_Control, Status, Mouse_Buffer, Time_Stamp); 


function Engage(TARGET_INFO : in Target. TARGET_DATA_LIST_TYPE) return 


Target.TARGET_ID_TYPE is 


use Types; -- for operators 

use Status; -- for operators 

RETICLE _X_PIXEL : Types.WORD; -- reticle in PIXEL coordinates 
RETICLE_Y_PIXEL : Types.WORD; -- reticle in PIXEL coordinates 
RETICLE X_ GRID : Types.METERS; -- reticle in GRID coordinates 
RETICLE _Y_ GRID : Types.METERS; -- reticle in GRID coordinates 
PREV_OISTANCE : Types.METERS; 

OISTANCE_X : Types.METERS; 

DISTANCE_Y : Types .METERS := Config.meters_in_battle area; 
TOTAL_DISTANCE : Types. METERS; 

TARGET_ID : Target. TARGET_1D_TYPE; 

begin 


-°$TP(0018) Engage start 
ΤΑΛΟΕΙ͂ [0 := 0; -> default 
if Status.STATUS_CONTROL (Status .AIRBORNE).DATA < Config.max_rockets then 
if Stetus.MODE = Status.MANUAL then 
{f Mouse_Buffer.LAUNCH then 
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~- read ABS_X and ABS_Y in Mouse_Buffer, then convert to METERS types. 
-- Then, find closest target in list to reticle, and give fit back. 
Interrupt_Control .disable; -- go atomic while reading 
RETICLE_X PIXEL := Mouse Buffer .NEW_ABS_X; 
RETICLE_Y_PIXEL :2 Mouse_Buffer.NEW_ABS_Y; 
Mouse_Buffer.LAUNCH := FALSE; 
Interrupt_Control .Enable; 
RETICLE_X_GRID := 
Types .METERS( Types .METERS(RETICLE_X PIXEL - 
Config.battlefield_screen_left) * 
Types .METERS(Config.meters_per X_pixel)); 
RETICLE_Y_GRID :3 
Types .METERS( Types .METERS(Config.battlefield_screen_bottom - 
RETICLE Y_ PIXEL) * 
Types .METERS(Config.meters_per_Y_pixel)); 
-- This loop locates the closest target to the reticle center 
for ID in Types. TARGET_INDEX_TYPE loop 
if TARGET_INFOCID).STATUS.ACTIVE and then 
Not TARGET_INFOCID).STATUS.ENGAGED then 
DISTANCE_X :Ξ abs(RETICLE_X GRID - TARGET_INFO(ID).POSITION_NEW.X); 
DISTANCE_Y :5 abs(RETICLE Y_GRID - TARGET_INFOQ(ID).POSITION_NEW.Y); 
if OISTANCE_X <= Shapes.reticle_X_error and 
DiSTANCE_Y <= Shapes.reticle_Y_error 
then 
TOTAL_DISTANCE := Types. METERS(DISfANCE_X * DISTANCE _X) + 
Types .METERS(DISTANCE_Y * DISTANCE Y); 
1f TARGET_IO = 0 or else TOTAL_DISTANCE < PREV_OISTANCE tien 
PREV_DISTANCE := TOTAL_DISTANCE; 
TARGET_ID := 1D; 


end if; -- distance/target check 
end if; -- x and y reticte distance check 
end if; -- active/not engaged check 
end loop; 
end if; ++ leunch check 
else -- gutomatic mode, search for closest Y value 


for ID in Types. TARGET_INDEX_TYPE loop 
if TARGET_INFO(IO).STATUS.ACTIVE and then 
(mot TARGET_INFO(1D).STATUS.ENGAGED and 
TARGET_INFO(1D) POSITION _NEW.Y <= DISTANCE_Y) 
then 
DISTANCE_Y := TARGET_{NFOCID).POSITION_NEW.Y; 
TARGET_ID := 1D; 


end if; “- active/not engaged/closest y check 
end loop; 
end if: -- mode check 
end if; -- mumber of rockets check 


--$TP(0019) Engage end 
return TARGET_ID; 
end Engage; 
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o-] UNIT: Graphics Package Spec. “- 
--| Effects: Performs all updates to graphics display. -- 
κὉ. Modifies: No global dats is modified. “- 
τ Requires: Screen must be put in graphics mode by runtime initialize.-- 
τ Raises: QUEUE_ERROR is raised if no room for move list. 55 
“5 Engineer: T. Griest / M. Sperry. -- 
-- Date : 10-10-88 

-- Purpose : 


-- The Graphics package provides the interface for all screen display 

-- operations. All sctivity is performed by the Display task which insures 

-- that the display is updated in a consistent and timely (c. 100 msecs.) 

-- fashion. The shapes supported are defined in the Shapes package. 

στ The initialization in the run-time places the screen in high resolution mode 
-- of the EGA’s possible types and also sets it to write mode two. The pixel 
-- coordinates passed to the display task are passed as an array of records, 

-- where the PIXEL component is in screen coordinates, not meters. Pixels are 
-- defined in high resolution mode as 640 (x) by 350 (y). Note that the y 

-- direction is positive going down. 


with Types; 

with Config; 

with Shapes; 

package Graphics is 

stack_size : constant :5 8192; “τ in bytes 


τα define screen and graphics constants 


subtype COLOR_TYPE is Types.WORD; -- range 0..63; -- 64 colors om EGA 


background color : constant COLOR TYPE := 0; -- black 

reticle color : constant COLOR _TYPE := 4; -- red 

border_color : constant COLOR_TYPE := 2; -- green 
status_color 3 constant COLOR_TYPE := 7; τ white 

status_box_ color : constant COLOR_TYPE := 2; -- green 
rocket_color 3 constant COLOR_TYPE := 9; το bight blue 
target_color : constant array(Types.TARGET_CLASS_TYPE, BOOLEAN) of 


COLOR_TYPE :2 ((6, 14), (3, 11), (2, 10), (5, 139); 
-- different color for engage = false/true and target type 
no_process : constant COLOR TYPE :5 16; -- don’t process object color 


“- define graphics data structures 
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type PrIVE_RECORD is record 


XY_OLO : Shapes PIXEL; 

XY_NEW : Shapes.PIXEL; 

OBJECT 3 Shapes .O@JECT_TYPE; στ list of relative offsets 

COLOR : COLOR_TYPE; -- if > 15, ignore this motion request 
end record; 


type MOVE_LIST TYPE is array (Types.WORO_INDEX range <>) of MOVE_RECORD; 
type PRIORITY TYPE is (HIGH, LOW); 


QJEUE_ERROR s exception; το if queue over/under flow 


task type Display_Type is 
entry Move(PRIORITY : PRIORITY TYPE: WORK_LIST : MOVE_LIST_TYPE); 
pragma PRIORITY(Config.display_priority); 
end Display Type; 
for Display_Type’ STORAGE SIZE use INTEGER(Config.bytes_per_storage_unit * 
stack_size); 
Display : Display_Type; 


end Graphics; 
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+>| UNIT: Graphics Peckage Sody -- 
55 Effects: Performs all updates to graphics display. -- 
++] Modifies: No global data is modified. -- 
“τὶ Requires: Screen must be put in graphics mode by runtime initialize.-- 
στ Raises: QUEUE_ERROR is raised if no room for move list. τ" 
--| Engineer: 7. Griest ) Μ. Sperry. --: 


στ The purpose of the graphics package body is the implementation of the 

-- display task on am EGA board. The display task is responsible for buffering 
-- the various tasks that went to draw their particular symbol and the screen. 
-- The task begins by waiting for a work request to draw a symbol. Then, when 
τ 8 request comes in, it is put om 8 queue. The queue it goes on is a function 
++ of the callers’ priority. Then, since there is work to do, it processes one 
στ symbol on the list and rechecks for higher priority work requests until no 

~- work on any priority is left. 


with Machine_Dependent; 

with Interrupt_Control; 

with Debug_10; 

with Time_Stamp; 

pragma ELABORATE (Machine Dependent, Interrupt_Control, Debug_!0, Time_Stamp); 


package body Graphics is 


task body Display Type is 
use Types; “- needed for visibility to "+" operator 


buffer_size : constant : 256; 


type CIRCULAR_BUFFER is array(Types.WORD_INOEX range 0 .. buffer_size - 1) of 
MOVE_RECORD; 


type BUFFER_TYPE is record 
OW : Types.WORD_INOEX := 0; 
OFF : Types.WORO_INDEX := 0; 
DATA : CIRCULAR_BUFFER; 

end record; 


SET_PRIORITY : PRIORITY_TYPE := PRIORITY _TYPE’FIRST; 

BUFFER 2 array(PRIORITY TYPE’FIRST. .PRIORITY_TYPE‘LAST) of BUFFER TYPE; -- set up queues 
NO_WORK : BOOLEAN; “τ all queues empty? 

WORK_REQUEST : MOVE_RECORD; “- for individual processing 
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OBJECT : Shapes .OBJECT_PTR; -- current-object to move 


procedure Write_To_Screen(WORK_REQUEST : MOVE_RECORD) is 


-- A procedure which positions the cursor on the screen (based on the XY_NEW 
-- field im the MOVE_RECORD), then prints the string advancing the cursor 


-- after each character is printed. The string is printed character by 


-- character to ensure that there are no dependencies on the representation of 


-> the type STRING. 


bagin 
Machine_Dependent write _Mode_0; 
Machine_Dependent .Position_Cursor(WORK_REQUEST.XY_NEW.X, 
WORK_REQUEST .“Y_NEW.Y); 
for 1 in 1..Config.stats_title_max_ length loop 
Machine_Dependent γί τας WORK REQUEST .OBJECT.TEXT_OBJECT(1), 
WORK_REQUEST . COLOR); 
end loop; =“ 
Machine_Dependent .Write_Mode_2; 
end Write_To_ Screen; 


procetire Erise_Image(BASE 
ITEM 


Shapes .PIXEL; 
Shapes .OB8JECT_PTR) is 


- A pr-vedure designed to calculate absolute coordinates for Put Pixel 
- olacing “he pixel ia the background color, thus erasisg. 


begin 
--$7P(0020) Graphics.Erase_Image start 
for I in ITEM.all’range loop 
Machine Dependent .Put_Pixel(BASE.X + ITEM.alt(1).X_OFFSET, 
BASE.Y + [TEM.all(1).Y_OFFSET, 
background_color); 
end loop; 
--$TP(0021) Graphics.Erase_Image end 
end Erase_Image; 
pragma INLINE(CERASE_ IMAGE); 


procedure Draw_Image(BASE : Shapes.PIXEL; 
ITEM : Shapes .OBJECT_PTR; 
COLOR : COLOR_TYPE) is 


-- A procedure designed to calculste absolute coordinates for Put_Pixel 
στ turning on the pixel in the given color. 


begin 
-*$TP(0022) Graphics.Oraw_Image start 
for | fim ITEM. all’range loop 
Machine_Dependent.Put_Pixel(BASE.X * ITEM.al((1).X_OFFSET, 
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BASE.Y + ITEM. al((1).Y_OFFSET, 
COLOR); 
end loop; 
--$TP(0023) Graphics.Oraw_Image end 
end Draw_Image; 
pragma INLINE(DRAW IMAGE); 


procedure [nitialize Border is 
-- A procedure used to place a color border around the battlefield limits. 
BORDER : MOVE_RECORD; 


begin 
BORDER OBJECT PIXEL OBJECT := Shapes .DOT; 
OBJECT := Shapes.OBJECT_PTR_TABLE( BORDER .OBJECT PIXEL OBJECT); 
BORDER .COLOR :» border_color; 


-- draw top and bottom border 
for I in Contig.border_left..Config.border_right loop 
BORDER.XY_NEW :# (Types.COORDINATE(1), Config.border_top); 
Draw_Image (BORDER .XY_NEW, OBJECT , BORDER .COLOR); 
BORDER.XY_NEW := (Types. COORDINATE(1),Config.border_bottom); 
Draw_Image( BORDER .XY_NEW, CBJECT , BORDER .COLOR); 
end loop; 


-- draw teft side and right side border 
for J in Config.border_top. .Config.border_bottom loop 
BORDER.XY_NEW :Ξ (Config.border_left, Types.COORDINATE(J)); 
Oraw_Image( BORDER .XY_NEW, OBJECT , BORDER .COLOR); 
BORDER .XY_NEW :5 (Config.border_right, Types. COORDINATE(J)); 
Oraw_Image(BORDER .XY_NEW, OBJECT , BORDER.COLOR); 
end loop; 
exception 
when others => Debug _!0.Put_Line("Exception raised in Graphics. Initialize"); 
end Initialize Border; 


procedure Enqueve(PRIORITY : PRIORITY TYPE; MOVE_REQUEST : MOVE_RECORD) is 


-- A procedure which enqueves a MOVE_RECORD onto the proper priority queue for 
“τ Cater processing. May raise QUEVE_ERROR. 


ΟΝ ΝῈΜ : -Types.WORD_ INDEX; 


begin 
-°$TP(0024) Graphicsa.Enqueue start 
OM_WEW := (BUFFERCPRIORITY).OM + 1) rem buffer_size; 
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if ON_NEW = BUFFER(PRIORITY).OFF then % 
raise QUEVE_ERROR; 
end if; 
Interrupt_Control .disable; -- compiler bug 
BUFFERCPRIORITY) .DATACON_NEW) := MOVE_REQUEST; 
Interrupt_Control .Enable; -- 
BUFFERCPRIORITY).ON :5 ON_NEW; 
--$TP(0025) Graphics.Enqueue end 
end Enqueue; 
oragma INLINE (Enqueue); 


procedure Deqweue(PRIORITY : PRIORITY_TYPE; MOVE_REQUEST : out MOVE_RECORD) is 


ΙΑ procedure to remove a MOVE_RECORD for processing. May raise QUEUE_ERROR. 


OFF_NEW : Types.WORD_INDEX; 

begin ΄ 
--$TP(0026) Graphics.Dequeue start 
if BUFFERCPRIORITY).OFF 2 BUFFERCPRIORITY).ON then 

raise QUEVE_ERROR; 

and if; 
GFF_NEW :* (BUFFERC(PRIORITY).OFF + 1) rem buffer_size; 
interrupt_Contro( .Ofsab(e; -- compiler bug 
. YE_REQUEST 22 BUFFERCPRIORITY) .CATACOFF_NEW); 
sii serupt Control .enable; -- 
BUFFERCPRIORITY).OFF := OFF_NEW; 
--$TP(0027) Graphics.Dequeue end 

end Dequeue; 

pragma INLINE (Dequeue); 


e+ Body of DISPLAY TASK 55 


ςοοσοοτοοοσσσοσοσσ στ στο σσ“55555.. -..... 


begin 
NO_WORK :5 TRUE; 
dachine_ Dependent. Initial ize_Screen; το hi-res graphics 
Machine Dependent .Write_Mode_2; -- go to write mode 2 
Initialize Border; -- draw battlefield border 
loop 
begin -- exception block 


-°$TP(u028) Graphics task start 
if NO_WORK or Move’COUNT > 0 then 
--$TP(0112) Graphics accept Move start 
accept Move(PRIORITY : PRIORITY_TYPE; WORK_LIST : MOVE_LIST_TYPE) do 
for I in WORK_LIST’ range loop 
{f WORK_LIST(I).COLOR <= 15 then “. process this symbol? 
Enqueue(PRIORITY, WORK_LIST(1)); 
end if; 
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end loop; 
end Move; 
--$TP(0113) Graphics accept Move end 
WO_WORK := FALSE; 
end if; 
«= Now there is some work to do, see if any left on highest priority 
SET_PRIORITY 32 PRIORITY_TYPE’ FIRST; 
loop 
if BUFFERCSET_PRIORITY).ON /2 BUFFER(SET_PRIORITY) .OFF then 
Dequeue(SET_PRIORI TY, WORK_REQUEST ); -- at this point, requests real 
case WORK_REQUEST .OBJECT -OBJECT_MODE is 
when Shapes.TEXT_MODE => Write_To_Screen(WORK_REQUEST); 
when Shapes .PIXEL_MODE => 
OBJECT :- Shapes .OBJECT_PTR_TABLE(WORK_REQUEST OBJECT .PIXEL_OBJECT); 
Erase_Image(WORK_REQUEST.XY_OLD, OBJECT); 
Oraw_Image (WORK_REQUEST .XY_NEW, OBJECT, WORK_REQUEST .COLOR); 


end case; 

NO_WORK := FALSE; 

exit; => leave loop if we processed a request 
else 

NO_WORK := TRUE; -- default 


exit when SET_PRIORITY = PRIORITY_TYPE ‘LAST; 
SET_PRIORITY := PRIORITY_TYPE’ SUCC(SET_PRIORITY); 
end if; 
end loop; 


exception 
when QUEUE_ERROR => null; -+ since error is propagated to caller 
when others => 
Debug_10.Put_Linec"Error in Display Task"); 
end; -- exception block 
--$TP(0029) Graphics task end 
end loop; 
end Display_Type; 


end Graphics; 
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--| UNIT: Grid_to_ Pixel Function Spec. -- 


τι Effects: Converts battlefield meters X-Y to graphics Pixel X-Y. -- 
--[ Modifies: No global data is modified. “- 
--| Requires: No initialization is required. “ 
51 Raises: No explicitly raised exceptions are propagated. “- 
o-| Engineer: T. Griest. “- 


with Shapes; 
with Types; 
function Grid_to_Pixel(GRID : 
pragma INLINE(Grid_to_ Pixel); 


in Types.POSITION_TYPE) return Shapes.Pixel; 
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--| UNIT: Grid_to_Pixel Function Spec. -- 
στ Effects: Converts battlefield meters ΧῪ to graphics Pixel X-Y. “-- 
τῇ Modifies: No global data is modified. “Ξ 
5 Requires: No initialization is required. -- 
τὶ Raises: No explicitly raised exceptions are propagated. “- 
--| Engineer: T. Griest. -- 


--.--..- ΕΣ ΎΧΧΧΎΧΧ ΎΧ Σ 


with Config; 
with Time_Stamp; 
pragma ELASORATE(T ime_Stamp); 


-- Translate from Battlefield Grid coordinates in meters to pixels 
το om the screen. This means applying scale factors for x/y and 

-* providing offsets to battlefield area on screen. NOTE: since 

-- battlefield coordinates have 0,0 in lower left; and graphics 

το coordinates have 0,0 in upper left, this involves a transpose of 
το the Y axis (thus the ’-"). 


function Grid_to_Pixel(GRID : in Types.POSITION_TYPE) return Shapes.Pixel is 
use Types; 
PIX : Shapes.PIXEL; 
begin 
--$TP(0030) Grid_To_Pixel start 
PIX.X := Config.battlefield_ screen _left + 
Types .COORDINATE(GRIO.X / Types.METERS(Config.meters_per_x_pixel)); 
PIX.Y := Config.battlefield_screen_bottom - 
Types .COORDINATE(GRID.Y / Types.METERS(Config.meters_per_y_pixel)); 
-- Was previously below return (1-04-89 MPS) 
--$TP(0031) Grid_To_ Pixel end 
return PIX; 
end Grid_to_ Pixel; 
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++] UNIT: Guidance Task Subunit -- 
τι Effects: Calls “Guide" to compute next rocket aimpoint for every “- 
<-{ ective rocket in the input list. πὰ 
τς Modifies: No σἰοδοὶ data is modified. == 
τ Requires: No initialization is required. -- 
--{ Raises: No explicitly raised exceptions are propagated. = 
--{ Engineer: 7. Griest. “- 


“οοοσουσ το συσ σου weveescaccoes ΥΩ ace 


with Guide; 

with Time Stamp; 

with Interrupt_Control; 

pragma ELABORATE(Guide, Time_Stamp, Interrupt_Control); 


separate(Rocket) 

“τ Task Type GYIDANCE is used to create an array of tasks which compute 
+- guidance information for a specified mumber of rockets. 

task body Guidance_Type is 


use Types; -- for operator visibility 
NEXT _GUIDE_LIST AIMPOINT _LIST_TYPE(1..Config.max_rockets); 


WEXT_HISTORY_LIST : HISTORY LIST _TYPE(1..Config.max_rockets); 
FIRST_ROCKET_1D 2 Types.WORD_INDEX; 
LAST_ROCKET_ID 3 Types.WORD_INDEX; 


-- Guide computes new aimpofnt for rocket based on previous positions 
-- function Guide(POS : POSITION_PAIR_TYPE) return Types.AIMPOINT TYPE 


“- is separate; 
begin 
loop 51] main processing loop 
begin κι exception block 


+-$TP(0032) Guidance task start 


-- Get history information for our target/rocket list and make local copy. 
-- Index of history array is ROCKET_ID. The entire Guide List array is 
-- used, even though many of the entries may be inactive. The engagement 
στ task is responsible for filtering out only active rockets for issuing 
-- the guidance messages. 


--$TP(0033) Guidance accept History start 

accept History(HISTORY_OATA : in KISTORY_LIST_TYPE) do 
FIRST_ROCKET_ID := HISTORY_DATA’ first; 
LAST_ROCKET_ID := HISTORY_DATA‘ last; 
Interrupt_Control .Disabdle; 
WEXT_HISTORY_LISTCFIRST_ROCKET_[0..LAST_ROCKET_ID) := HISTORY_DATA; 
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Interrupt_Control .Enable; 
end History; - 
--$TP(0034) Guidance accept History end 


στ process list to create guidance information 


for ROCKET_ID in FIRST_ROCKET_ID..LAST_ROCKET_ID loop 
if NEXT_HISTORY_LISTCROCKET_ID).ACTIVE then 
WEXT_GUIDE_LISTCROCKET_ID) :5 
Guide(NEXT_HISTORY_LIST(ROCKET_ID).POSITION_PAIR); 
end if; 
end loop; 


-*$TP(0035) Guidance accept Next_Guidance start 
accept Next_Guidance(AIMPOINT LIST : out AIMPOINT_LIST_TYPE) do 
if AIMPOINT_LIST’ first /= FIRST_ROCKET_ID or 
AIMPOINT_LIST’last /# LAST_ROCKET_ID 
then 
raise GUIDANCE_LIST_ERROR; 
else ° 
Interrupt_Control .Disable; 
AIMPOINT_LIST := NEXT_GUIDE_LIST(FIRST_ROCKET_I!D..LAST_ROCKET_I0); 
Interrupt_Control .Enable; 
end if; 
end Next_Guidance; 
--$TP(0036) Guidance accept Next_Guidance end 


exception 
when others 3» 
Debug_10.Put_Line("Error in GUIDANCE TASK"); 


end; --| exception block 
--$TP(0037) Guidance task end 
end loop; τι main processing loop 


end Guidance_Type; 
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o-| UNIT: Guide Function Spec. 


°-| Effects: Computes 8 new aimpoint based on rocket/target positions. 


-+| Modifies: No global data is modified. 

--[ Requires: No initialization is required. 

--] Raises: Wo explicitly raised exceptions ere propagated. 
--| Engineer: T. Griest. 


with Types; 


function Guide(POS : Types.POSITION_PAIR_TYPE) return Types .AIMPOINT_TYPE; 


pragma INLINE(Guide); 


-103- 


Demonstration Project Final Report 


PTT TTT TTT TTT ποτ π 6655. 55.6.9 wweacarocosococes 


΄ 


o-] UNIT: Guide Function Body. -- 
5 Effects: Computes a new simpoint based on rocket/target positions. -- 
>| Modifies: No global data is modified. -- 
.- Requires: No initialization is required. : os 
τ Raises: No explicitly raised exceptions are propagated. “- 
5. Engineer: T. Griest. 7 
with Types; 


with Math; 

with Config; 

with Time_Stamp; 

pragma ELABORATE(Math, Time_Stamp); 


-+ The Guide function takes the most recent two postions of a rocket/target 
-- pair, and computes an aimpoint for the rocket to intercept. 

++ Several optimizations are used to provide good average and worst-case 

+--+ performance: 


-- 1) Rough approximations are used when the rocket is more 
τ than a specified closing_time away in any axis; 
-- 2) rather than using a composite velocity vector, discrete 


-- velocities and distances are used for X,Y, and Z to eliminate 

-- the need for square root; 

-- and a greatly simplified arctan routine is used to approximate (within 

-- 5 degrees of accuracy) the arctan function using a simple multiply. 

-- This also simultaneously converts the fixed point type to BAMs (see Types). 


function Guide(POS : Types.POSITION_PAIR_TYPE) return Types.AIMPOINT_TYPE is 
use Types; -- for operators 


climb_Point 
control_time 


constant := 500.0; -- climb to 500 meters altitude first 
constant :5 20; -- last 20 intervals (2 seconds) 


type AXIS_TYPE is (X, Y , 2); 


MAX_AXIS 
MAX_OIST 


AXIS_TYPE; 
Types .METERS; 


type POSITION_ARRAY_TYPE is array(AXIS_TYPE) of Types.METERS; 


TARGET_POS : POSITION_ARRAY_TYPE; 
ROCKET_OELTA 3 POSITION_ARRAY_TYPE; 
TARGET _DELTA 3 POSITION_ARRAY_TYPE; 
AXIS_OIST ς POSITION_ARRAY_TYPE; 
O1ST_XY Types.METERS; “- used to project Z on ΧΟῪ 


590 Χ Types.LONG_FIXED; -- for squaring 
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so_y 


ϊ Types .LONG_FIXED; - 
SQ_XY 


Types.LONG_FIXED; 


WEXT_AIMPOINT 3 Types. AIMPOINT_TYPE; 


CLOSING_RATE : Types .METERS; “- METERS per intervai 
CLOSING TIME : Types .WORD; -- number of intervals 
MAX_CLOSING_TIME : Types.WORD; -- worst case num of intervals 


begin 
-*$TP(0038) Guide start 


το First determine if rocket is in boost phase (initial climb to altitude), 
τι if so, simply maintain climb. NOTE: This technique assumes that the 

στ rocket will never fly straight and level below the climb point. This 

-- implies that the climb_point is sufficiently high that the ingress phase 
-- has a constant downward slope. If this turns out not to be the case, 

το the rocket will jump up to altitude unexpectantly when trying to fly 

τα level below the climb_point. The expected scenario prevents this 

το from happening. However, to make this more robust, a time_of_flight 

-- could be maintained which would determine when to complete the boost 

-- phase. 


ROCKET_DELTACZ) :2 POS.ROCKET_NEW.Z - POS.ROCKET_OLD.Z; -- rocket change in Z 
if ROCKET_DELTA(Z) >= 0.0 and POS.ROCKET_NEW.Z « climb_point 
then -- still in boost 
WEXT_AIMPOINT :# (Config. launch_azimuth, Config. launch elevation); 
else στ must do some guidance 


τι Now determine how far away the target is in each axis 
AXIS_DIST(X) 


AXIS_DISTC(Y) 
AXIS_DIST(Z) 


= POS.TARGET_NEW.X - POS.ROCKET_NEW.X; -- target/rocket X 
POS.TARGET_NEW.Y - POS.ROCKET_NEW.Y;  -- target/rocket Y 
= POS.TARGET_NEW.Z - POS.ROCKET_NEW.Z; -- target/rocket 2 


ROCKET_DELTAC(X) := POS.ROCKET_NEW.X 


8 POS .ROCKET_OLD.X; -- rocket change X 
ROCKET DELTACY) := POS.ROCKET_NEW.Y 


POS..ROCKET OLD.Y; -- rocket change Y 


TARGET _DELTACX) 
TARGET_DELTACY) 
TARGET _DELTA(Z) 


= POS. TARGET_NEW.X 
POS. TARGET_NEW.Y 
= POS. TARGET_NEW.2 


POS.TARGET_OLD.X; -- TARGET change X 
POS. TARGET _OLD.Y; -- TARGET change Y 
POS. TARGET _OLO.Z; -- TARGET change Z 


τ. Compute the farthest distance "MAX_DIST“ and the closing rate for that 
“- axis. 


MAX_CLOSING TIME := -1; 
for AXIS: in AXIS_TYPE loop 
CLOSING_RATE := ROCKET_DELTACAXIS)- TARGET_DELTACAXIS); 
“+ make sure next calculation will not overflow METER type 
if CLOSING_RATE /= 0.0 amd abs AXIS DISTCAXIS) < 500.0 then 
CLOSING _TIME :5 Types.WORD(AXIS DISTCAXIS) / CLOSING_RATE); 
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if CLOSING TIME < 0 then 
MAX_CLOSING_TIME := Types.WORD‘ Last; 
else 
if CLOSING _TIME > MAX_CLOSING_TIME then 
MAX_CLOSING_TIME := CLOSING_TIME; 
WAX_AXIS := AXIS; 
end if; 
end if; 
end if; 
end loop; 


΄ 


-- Compute number of intervals before target/rocket intercept. 

c- Note: this operation’s accuracy depends on the rounding algorithm used... 
τ If the Rocket is close (in time) to the Rocket, do extra work 

*- of extrapolating the Targets position at intercept 


if MAX_CLOSING_TIME > 0 and 
MAX_CLOSING_TIME < control_time then -- extrapolate 
AXTS_DIST(X) :# AXIS _DIST(X) + TARGET_DELTACX)*INTEGER(MAX_CLOSING TIME); 
AXIS_DISTCY) :π AXIS_DISTC(Y) + TARGET_DELTACY)*INTEGER(MAX CLOSING TIME); 
AXIS_DIST(Z) :5 AXIS _DIST(Z) + TARGET_DELTA(Z)*INTEGER(MAK_CLOSING TIME): 
end if; 


στ Now compute angle for Azimuth and Elevation to 
στ relative target position (possibly extrapolated) for this rocket. 


NEXT_AIMPOINT AZIMUTH © := Math. Arctan(AXIS_DIST(X),AXIS_DISTCY)); ° 
SQ_X := Types. LONG_FIXED(AXIS_DIST(X)); 
50 Χ := Types. LONG_FIXED(SG@_X " 56 Χ); 
SQ_Y :- Types.LONG ΡΙΧΕΌ(ΑΧΙΘ DISTCY)); 
SO_Y := Types.LONG_FIXED(SQ@_Y * 50 Υ}; 
SQ_XY := Math.Sqrt(S@_x + SQ@_Y); 
if SQ_XY > 4000.0 then 
NEXT_AIMPOINT .ELEVATION := -200;--fly almost level till rocket gets closer 
else 
DIST_XY :2 Types.METERS(SQ_XY); 
NEXT_AIMPOINT ELEVATION :® Math. Arctan(DIST_XY,AXIS_DIST(Z)); 
if NEXT_AIMPOINT.ELEVATION > -1026 then 
NEXT_AIMPOINT .ELEVATION := «1024; 
elsif NEXT_AIMPOINT ELEVATION < -16384 then 
NEXT _AIMPOINT ELEVATION :π5 -16384; 


end if; -- elevation check 
end if; “τ 80 ΧΥ too big check 
end if; -- no longer in boost check 


--$TP(0039) Guide end 
return NEXT_AIMPOINT; 
end Guide; 
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o-| UNIT: Guide_Suf Task Subunit -- 
--| Effects: Provides asynchronous cosm. between simulator and Control.-- 
--| Modifies: No global data is modified. -- 
“τ, Requires: No initialization is required. -- 
--| Raises: Wo explicitly raised exceptions are propagated. -- 
-.] Engineer: T. Griest. -- 


cee wewcscose weocccereane “οο στ οσ τσ το -..-...9.-5 α΄. οσοουσοσ συ σσοσοσπ-55.555-5- waves 


+> The Guide Buf task acts as a buffer between the rocket data Link 
το support task Rock_Sup and the Rocket.Control task which processes 
-- the rocket data. 


στ TIMING CONSIDERATIONS: Guide _Buf will only provide the most recent 
-- message received. If two messages are received prior to one being 
τ taken, the first will be lost. 


with Debug _I0; 
with Time_Stamp; 
pragma ELABORATE(Debug_!0, Time_Stamp); 


| separate (Simulate.ROL) 
| task body Guide Buf Type is 


use Types; 
GUIDE_MSG 
MSG_COUNT 
begin 
loop 
--$TP(0040) Guidebuf task start 
select 
accept Put_Guide(DATA : in Rocket .ROCKET_GUIDE_MSG_TYPE) do 
--$TP(0061) Guidebuf accept Put_Guide start 
GUIDE_MSG.NUM_ROCKETS := DATA.NUM_ROCKETS; -- copy data 
for 1 in Types.WORO_INOEX range 1..DATA.NUM_ROCKETS loop 
GUIDE_MSG.ROCKET_GUIDE_LIST(1) :* DATA.ROCKET_GUIDE_LIST(1); 


Rocket .ROCKET_GUIDE_MSG_TYPE; 
Types.WORD := 0; -- if a message has been buffered 


end loop; 
MSG_COUNT :- 1; -- only meaningful that it is > 0 
--$TP(0042) Guidebuf accept Put_Guide end 

end Put_Guide; 


or 

when MSG_COUNT > 0 => 

accept Get_Guide(DATA : out Rocket.ROCKET GUIDE_MSG_TYPE) do 
~-$TP(0043) Guidebuf accept Get_Guide start 
DATA.NUM_ROCKETS := GUIDE _MSG.NUM_ROCKETS; 
for I in Types.WORD_INDEX range 1..GUIDE_MSG.NUM_ROCKETS loop 

DATA.ROCKET_GUIDE_LIST(I) := GUIDE_MSG.ROCKET_GUIDE_LIST(I); 

end loop; 
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MSG_COUNT :3 1; -- do keep multiple copies 
--$TP(0044) Guidebuf accept Get_Guide end ~ 
end Get_Guide; 
end select; 
~-$TP(0045) Guidebuf task end 
end loop; 
exception 
when others => 
Debug_!0.Put_Line("GUIDE_BUF termination due to exception."); 
end Guide Suf_Type; 
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--| UNIT: Interrupt_Control Package Spec. and Body. -- 
--[ Effects: Provides controt over interrupt flags. -- 
++| Modifies: No global data is modified. -- 
“:| Requires: No initialization is required. “- 
5: Raises: No explicitly raised exceptions are propagated. *- 
τὶ Engineer: M. Sperry. .- 
ὧν ἢ -- Date 3 11-09-88 
“τ Purpose : 


-- The purpose of the Interrupt_Control package is to provide Ada level 

-- semantics for disabling and enabling interrupts on the 80X86 family of 

-- processors. Also for clearing the direction fiag because of an RTE bug 
“- which does ποῖ always clear it. 


with Machine Code; 
use Machine Code; 
pragma ELABORATE (Machine_Code); 


package Interrupt_Control is 
pragma SUPPRESS(Elaboration_Check); 


procedure Disable; 
pragma [NLINE(Disable); 
procedure Enable; 
pregme INLINE(Enable); 


procedure Clear_Oirection_Flag; 
pragma INLINE(Clear_Direction_Flag); 


end Interrupt_Control; 
package body Interrupt Control is 


procedure Disable is 
begin 

MACHINE_INSTRUCTION/ (none,m_CL1); 
end Disable; 


procedure Enable is 
begir: 

MACHINE INSTRUCTION’ (none, ἢ 571); 
end Eneble; 


procedure Clear _Direction_Flag is 
begin 

MACHINE INSTRUCTION’ (none,m_CLO); 
end Clear_Direction Flag; 


-109- 


Demonstration Project Final Report 


end Interrupt_Control; 
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στ UNIT: Machine_Dependent Package Spec. 7 -- 
--| Effects: Provides graphics machine dependencies. “- 
τι. Modifies: No global data is modified. -- 
++] Requires: No initialization is required (other than graphics mode). -- 
--| Raises: No explicitly raised exceptions are propagated. -- 
“1] Engineer: M. Sperry. -- 
τ Date 2 11-04-88 

-- Purpose ; 


-- The purpose of the Machine_Dependent package is to provide a separate 
στ package from the Ada code for drawing on an EGA high resolution screen via 
-- code statements. 


with Machine Code; 

with Graphics; , 

with Types; 

use Machine_Code; 

pragma ELABORATE (Machine_Code); 


package Machine Dependent is 
procedure Put_Pixel(ABS_X, ABS_Y 


COLOR 
pragma INLINE(Put_Pixel); 


Types . COORDINATE; 
Graphics.COLOR_TYPE); 


procedure Initialize_Screen; 
pragma INLINE(Initialize Screen); 


procedure Write_Mode_0; 
pragma INLINE(Write_Mode_0); 


procedure Position _Cursor(X,Y : Types.COORDINATE); 

pragma (NLINECPosition_Cursor); 

procedure Write(CHAR 
COLOR 

pragma INLINE(Write); 


CHARACTER; 
Graphics.COLOR_TYPE); 


procedure Write_Mode_2; 
pragma INLINE(Write_Mode_2); 


end Machine _Oependent; 
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--| UNIT: Machine_Dependent Package Body. 6 -- 
56} Effects: Provides graphics machine dependencies. -- 
“1 Modifies: No global data is modified. -- 
τῷ Requires: No initialization is required (other than graphics mode). -- 
+-| Raises: No explicitly raised exceptions ere propagated. -- 
55} Engineer: M. Sperry. -- 


package body Machine_Dependent is 


ΤΑ machine dependent package which makes use of the functionality of the 
+- Phoenix BIOS routines to perform some graphics processing. The BIOS call 
-- used is at C000:0CD7 (which is INT 10 on most EGA adapters). 


hi_res_graphics : constant := 16#10#; τα graphics mode 

set_cursor 3 constant :5 16402004; στ set cursor function 
page_zero : constant := 16#00#; -- set cursor to active page 
write function ,Ξ3 constant := 16#0E#; 

index_register : constant := 16#3CE#; -- port address 

access _register : constant := 16W3CF#; “- port address 
mode_register : constant := 5; -- index register 5 
write πούς 2 val : constant := 2; 

write_mode_O val : constant := 0; 


procedure Put_Pixel(ABS_X, ABS_Y : Types. COORDINATE; 
color : Graphics.COLOR_TYPE) is 


-- An assembly level procedure (for enhanced speed) to place s dot on the EGA 
στ screen. Write mode two is used here (again, for enhanced speed). [t is 
-- important to note that this routine is cailed more frequently that any 

-- other. 


begin. 
-+ The first thing to do is find out which bit must be turned on. This is 
-> done by taking SHR( 80h, ABS_X mod 8 ). The bit ordering goes from 7 -> 0. 


-“- 


MACHINE INSTRUCTION’ (register register, m MOV, CX, CX); -- defeat compiler bug 


MACHINE_INSTRUCTION’ (register_immediate, m_MOV, OX, 16#3CE#); -- select bit 
MACHINE_INSTRUCTION’{register_immediate, m_MOV, AL, 8); “- mask register 
MACHINE_INSTRUCTION’Cregister_register, m_OUT, DX, AL); -- in graphics chip 

+- Determine which bit must be turned on. This is 

-- done by taking SHR( 80h, ABS_X rem 8 ), reversing the bit ordering. 
MACHINE_INSTRUCTION’ (register_system_address, m_MOV, CX, ABS_X’ address); --X 
MACHINE_INSTRUCTION’ Cregister_register, m_MOV, BX, CX);  -- make copy of X 
MACKINE_INSTRUCTION’ Cregister_inmediate, m_AND, CL, 7); -- mask for bit # 
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MACHINE_INSTRUCTION’ (register_immediate, m_MOV, AL, 16#80#); -- most significant bit is 
MACHINE_INSTRUCTION’ (register_register, ἢ SHR, AL, CL); -- bit zero, do bit reversal. 

-- AL now holds the bit mask. Now give it to the bit mask register located 

“- at 1683CF#. 
MACHINE_INSTRUCTION’ (register, m_INC, DX); -- increment port address to 3CF 
MACHINE_INSTRUCTION’ (register_register, m_OUT, DX, AL); 


+> Now, latch the byte of graphics memory. The byte to latch 

++ is defined as (ABS_Y * 80) + (AB8S_X / 8). Then, when giving 

στ it back, place the color in AL. Note that only four bits of the color are 

++ significant and that the color placed in AL is not actually e color, but a 

-- palette register selection (from 0 to 15). The color in the palette 

-- register is the color displayed.-16#6000# is loaded (= AQOOH) 

τ. to point to the EGA graphics page zero memory address. 
MACHINE_INSTRUCTION’ (register_system_address, m_MOV, AX, ABS_Y’ address); 
MACHINE_INSTRUCTION’ (register_inmediate, m_MOV, CX, 80); -- bytes/line | 
MACHINE_INSTRUCTION’ (register, m MUL, CX); στ ABS_Y * 80 in AX 
MACHINE_INSTRUCTION’ (register_inmediate, m.MOV, CL, 3); -- Shift Count 
MACHINE_INSTRUCTION’ (register_register, m_SHR, BX, CL); -- ABS_X / 8 in BX 
MACHINE_INSTRUCTION’ (register_register, m_ADD, BX, AX); -- BX is offset 
MACHINE_INSTRUCTION’ (register_immediate, m MOV, AX, -16#6000#); -- base of RAM 
MACHINE_INSTRUCTION’ (register_register, m_MOV, ES, AX); 

++ Latch the palette selection. Note that the contents of AL upon return are 

+: meaningless, and that the color is latched internally to the EGA’s four bit 

-- planes. 
MACHINE_INSTRUCTION’ (register_address, m_MOV, AL, ES, BX, 0);-- mov al,es: (bx] 
MACHINE_INSTRUCTION’ (register _system_address, m_MOV, AX, COLOR’ address); 


e+ Finally, give the palette selection (color) to the four bit planes. 


MACHINE_INSTRUCTION’ (address_register, m_MOV, ES, BX, 0, AL);-- mov es: (ὈΧ] δὶ 


end Put_Pixet; 


-- Provide a mechanism to call ROM located routine to initialize screen 
procedure Inti0; τε spec of interface to 8105 graphics call 

pragma INTERFACE(ASM86, Inti0); 

pragma INTERFACE_SPELLING(Int10, “O1BIOS?7GRAPHICSCALL"); 


procedure Initialize_Screen is 
-- A procedure used to place an EGA screen into mode 10h, which is 640 x 350 
-° pixels. The screen is initially in write mode 0, which is different from 
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++ the graphics mode 10h. Later, in Change_To_Mode_2, the write mode is 
-- changed to mode 2. 


begin 
MACHINE_INSTRUCTION’ (register _immediate, m_MOV, AX, hi_res_graphics); 
MACHINE_INSTRUCTION’ (none, m_PUSHF); 
 MACHINE_INSTRUCTION! (register_system_address, m_CALL, Int10’Address); 
end Initialize_screen; 


procedure Write_Mode_0 is 

-- A procedure used to change the write mode of the screen to mode 0, for text 
-- writing. This procedure is called before writing the necessary statistics 
-- titles. 


begin 
MACHINE _INSTRUCTION! (register_inmediate, mMOV, DX, index_register); 
MACHINE_INSTRUCTION’ (register_immediate, m MOV, AL, mode_register); 
MACHINE_INSTRUCTION’(register_register, m_OUT, DX, AL); 
MACHINE_INSTRUCTION’ (register_immediate, m MOV, DX, access_register); 
MACHINE_INSTRUCTION’ (register_immediate, m_MOV, AL, write_mode_0 val); 
MACHINE_INSTRUCTION’ Cregister_register, m_OUT, DX, AL); 

end Write Mode 0; 


procedure Position _Cursor(xX,Y : Types.COORDINATE) is 
-- A procedure used to place the cursor where necessary (procedure Write 
-- only writes at the current cursor position). 


begin 
MACHINE_INSTRUCTION’ (register_immediate, m_MOV, AX, set_cursor); 
MACHINE_INSTRUCTION’ Cregister_system_address, m_MOV, OL, Χ' address); 
MACHINE_INSTRUCTION’ (register_system_address, m_MOV, DH, Y’ address); 
MACHINE_INSTRUCTION’ (register_immediate, m_MOV, 8X, page_zero); 
MACHINE_INSTRUCTION’ (none, m_PUSHF); 
MACHINE_INSTRUCTION’ Cregister_system_address, m_CALL, Int10’Address); 
end Position Cursor; 


procedure Write(CHAR CHARACTER; 

COLOR : Graphics.COLOR_TYPE) is 
++ A procedure used to place the character CHAR at the current cursor position 
“- on the screen which is in hi-res graphics mode, write mode 0. This procedure 
-- uses function call Oeh, which interprets ascii codes 10 and 13 as linefeed 
“- and carriage return respectively. The cursor can then be controlled so that 
“- a cheracter can be placed anywhere on the screen. 


begin 
MACHINE_INSTRUCTION’ Cregister_immediate, mMOV, AH, write function); 
MACHINE_INSTRUCTION’ (register_system_address, m_MOV, AL, CHAR’ address); 
MACHINE_INSTRUCTION’ (register_system_address, m_MOV, GL, COLOR’ address); 
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MACHINE_INSTRUCTION’ (none, m_PUSHF); 
MACHINE_INSTRUCTION’ Cregister_system_address,m_CALL, Int10’ address); 
end write; 


procedure Write_Mode_2 is 

-- A procedure used to change the write mode of the screen to mode 2, for pixel 
-- plotting. This procedure is catled after writing the necessary statistics 
στ titles. 


begin 
MACHINE_INSTRUCTION’ (register_immediate, m_MOV, DX, index_register); 
MACHINE_INSTRUCTION’ Cregister_immediate, m_MOV, AL, mode_register); 
MACHINE INSTRUCTION’ Cregister_register, m_OUT, DX, AL); 
MACHINE _INSTRUCTION’ Cregiste-_immediate, m MOV, DX, access_register); 
MACHINE _INSTRUCTION’ Cregister_imnediate, m_MOV, AL, write_mode_2 val); 
MACHINE_INSTRUCTION’ (register_register, m_OUT, DX, AL); 

end Write_Mode_2; 


end Machine_Oependent; 
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weuacence ΟΣ eres seracec eee eaanewressceseseseeeceeweveseawecesesecee 


΄ 


ΣΎΈ UNIT: Math Package Spec. =< 
το Effects: Compute various functions: Tan, Arc Tan, end Sart. -- 
51 Modifies: No global data is modified. . “- 
κι Requires: No initialization is required. -- 
--| Raises: No explicitly raised exceptions are propagated. -- 
τοῦ. Engineer: T. Griest. 55 
with Types; 


package Math is 

function Tan (ANGLE : Types.BAM) return Types.LONG_FIXED; 
function Sqrt(X : in Types.METERS) return Types.METERS; 
function Sqrt(X : in Types.LONG FIXED) return Types.LONG_FIXED; 


function Arctan(REL_X, REL_Y : in Types.METERS) return Types.BAM; 


end Math; 
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wee ewe econ eeccwewc ers eweesesecneeseeseereersceseroccceseseessaseseennsecs 


o-] UNIT: Math Package Body. 

--| Effects: Compute various functions: Tan, Arc Tan, and Sqrt. 
51 Modifies: No global data is modified. 

στῇ Requires: No initialization is required. 

51 Raises: No explicitly raised exceptions are propagated. 
55. Engineer: T. Griest. 


with Time_Stamp; 
pragma ELABORATE(Time_Stamp); 


package body Math is 
use Types; 


TAN_TABLE : array(Types.WORD range 0..90) of Types.LONG_FIXED := 
( 
0.00000, 0.01746, 0.03492, 0.05241, 0.06993, 0.08749, 0.10510, 
"0.16054, 0.15838, 0.17633, 0.19438, 0.21256, 0.23087, 0.24933, 
0.28675, 0.30573, 0.32492, 0.34433, 0.36397, 0.38386, 0.40403, 
0.44523, 0.46631, 0.48773, 0.50953, 0.53171, 0.55431, 0.57735, 
0.62487, 0.64941, 0.67451, 0.70021, 0.72654, 0.75356, 0.78129, 
0.83919, 0.86929, 0.90040, 0.93252, 0.96569, 1.00000, 1.03553, 
1.11061, 1.15037, 1.19175, 1.23490, 1.27994, 1.32704, 1.37638, 
1.48256, 1.53986, 1.60033, 1.664628, 1.73205, 1.80405, 1.88073, 
2.05030, 2.14451, 2.24604, 2.35585, 2.47509, 2.60509, 2.74748, 
3.07768, 3.27085, 3.48741, 3.73205, 4.01078, 4.33148, 4.70463, 


0.12278, 
0.26795, 
0.42647, 
0.60086, 
0.80978, 
1.07237, 
1.42815, 
1.96261, 
2.90421, 
5.14455, 


5.67128, 6.31375, 7.11536, 8.14434, 9.514636, 11.43005, 14.30067, 19.08114, 


28.63625, 57.28996, Types.sqrt_large_number ); 


function Tan (ANGLE : Types.BAM) return Types.LONG_FIXED is 
TANGENT : Types.LONG FIXED; 


THETA : Types. WORD; 
“- procedure Dummy is begin null; end; --(UNIX) 
-begin 
--STP(0048) Math.Tan start 
THETA :5 Types. WORD(ANGLE/ 182); τ approx. 182 bame per degree 


if THETA >= -90 and THETA <= 90 then 
if THETA >= 0 then 
TANGENT :- TAN_TABLE( THETA); 
else 
a3 Oummmy; - - (UNIX) 
TANGENT := -TAN_TABLE(-THETA); 
end if: 
elsif THETA < -90 then 
TANGENT := TAN_TABLEC(THETA + 180); 
else 
TANGENT :@ -TAN_TABLE(180-THETA); 
end if; 
*-$TP(0G49) Math.7an end 
return TANGENT; 
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end Tan; 


function Sart(x : in Types.METERS) return Types.METERS is 
use Types; -- import operators 
F : Types.METERS <= X; 
Y : Types.METERS := 1.0; 
OLD_Y : Types.METERS :2 Y; 
begin 
ΣΎ ΦΤΡ(ΟΟ50) Math.Saqrt start (METERS) 
for I in 1..15 loop 
exit when Y = 0.0; 
Y := (ΟΥ̓ + Types.METERS(F/Y) ) / 2; 
if Y = OLD_Y then 
exit; 
end if; 
OLD_Y := Y; 
end Loop; 
--$TP(0051) Math.Sqrt end (METERS) 
return Y; 
end Sqrt;. 


function Sqrt(X : in Types.LONG_FIXED) return Types.LONG_FIXED is 
use Types; -- import operators 
Fo: Types.LONG_FIXED := X; 
Y : Types.LONG_FIXED := 1.0; 
OLD_Y : Types.LONG_FIXED := Y; 
begin 
--$TP(0052) Math.Sqrt start (LONG_FIXED) 
for 1 in 1,.15 loop 
exit when Y = 0.0; 
Y := ΟΥ̓ + Types.LONG_FIXED(F/Y) ) / 2; 
if ¥ 3 OLD_Y then 
exit; 
end if; 
OLO_Y :2 Y; 
end loop; 
--$TP(0053) Math.Sqrt end (LONG_FIXED) 
return Y; 
exception 
when NUMERIC_ERROR => Y :Ξ OLD_Y; 
return Y; 
end Sqrt; 


*- A function used to return an approximation of the arctangent function. 
-- The maximum error allowed is five degrees off. The Arctan function 

-- computes the arctangent handling each quadrant on a case by case basis, 
-- since one general algorithm would violate the maximum error condition. 
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function Arctan(REL_X, REL_Y : in Types.METERS) return Types.BAM is 


type BIG_FIX is delta 0.125 range -200_000_000.0 .. 200_000_000.0; 


offset : constant Types.BAM :* 2 * 182; -- two degrees offset 
rotate_65 : constant BIG_FIX :5 8192.0; 
rotate_90 : constant BIG_FIX :5 163840; 
rotate_135 : constant BIG_FIX :# 24575 .0; 
x 2 BIG_FIX; 
Y : BIG_FIX; 
TEMP : BIG_FIX; 
ANGLE : Types .BAM; 
begin 


--$TP(0054) Math.Arctan sta7t 
X := BIG_FIXCREL_X); 
Υ := BIG_FIXCREL_Y); 
Quadrants: 
| 
1 | 1 
$/-180 -“τ-ττοτττττσσττσ 0 


Wr ot Iv 
if x < 0.0 then “τ Il or Il 
X 2@ °K; 
if Y < 0.0 then o> Ut 
Y 32 -Y; 
if X <= Y then -- upper 45 degrees 


X := BIG_FIX(X * 8192 / Y); 

Χ :- rotate_45 - X; 

X :- rotate_135 - X; 

ANGLE := Types.BAM(-X) - offset; 


else -- low 45 degrees 
TEMP := X; 
X 33 Y; -- convert 
Y : TEMP; 


X := BIG _FIXCX * 8192/Y); 
ANGLE :* Types.BAM(X) + offset *¢ Types.BAM’ first; 


end if; 
else “ὦ 
if xX <= 8ὲἁβ᾽ then -- upper 45 degrees 


K = BIG_FIX(X * 8192/Y); 
APALE 29 Types.BAM(X) + offset + 16384; 


else -- low 45 degrees 
TEMP := X; 
KX 38 Y3 
Y :s TEMP; 
Χ se BIG_FIX(X * 8192); 
Χ se BIG_FIXCX 7 Y); 
X :s rotate_45 - X; 
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X :8-X + rotate 135; 
ANGLE := Types.BAM(X); 


end if; 
end if; 
else -- Lor IV 
if Y < 0.0 then -- IV 
Y 32 -Y; 
if Χ <= Y then -- upper 45 degrees 


Χ : BIG_FIX(X * 8192/Y); 
ANGLE := Types.BAM(X) + offset - 16384; 


else “- low 45 degrees 
TEMP <= X; 
X32 Y; -- convert 
Y ss TEMP; 
X :- rotate_45 - BIG_FIX(X * 8192/Y); 
Χ πα X - rotate_45; 
ANGLE :* Types.BAM(X) - offset; 

end if; 

else eo I 
if x <Y then -- upper 45 degrees 


if Y - X >= X then 
X := rotate_45 + (rotate_45 - BIG_FIX(X * 8192 / Y)); 
else 
Χ := BIG_FIXCX * 8192 / (X + Y)); 
X := rotate_45 ὁ X; 
end if; 
ANGLE :2 Types.BAM(X); 
else -- low 45 degrees 
if Y 2 0.0 and X # 0.0 then 
ANGLE :5 Types.BAM(0); 
else 
TEMP :5 X; 
X33 Y; -- convert 
Y:= TEMP; 
Χ s= BIG_FIXCX * 8192/Y); 
ANGLE := Types.BAM(X) + offset; 
end if; 
end if; 


end if; 
end if; 


--$TP(0055) Math.Arctan end 
return ANGLE; 


end Arctan; 


end Math; 
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“.““-....5.5.. Pewee acces eeswocesecsensaceresicaoressesvebawcesewscveneensceweces 


o-| UNIT: Mouse Package Spec. -- 
--| Effects: Provides graphics pointing device interrupt handling. -- 
5.] Modifies: Status Mode, and Mouse_Buffer ΧῪ positions are updated. -- 


“τ Requires: Runtime initislization of interrupt vector. oo 
--{ Raises: Task will terminate on MOUSE_ERROR. “- 
--] Engineer: M. Sperry. “- 


-- Oate : 9-30-88 

-- Purpose : 

-- This is the specification for the package mouse. In addition to 
-- establishing communications with the mouse, a task is provided which 
e- handles the receive interrupt generated by the mouse at COM2. 


with System; pragma ELABORATE(System); 


package Mouse is 


procedure Initialize; 


task Char_In is 

pragma INTERRUPT _HANOLER; 

entry REPORT; 

for REPORT use at (16#83#,0)>. °- COM2 8250 serial port vector 
end Char_In; 


end Mouse; 
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++| UNIT: Mouse Package Body. - ἐν 
κα Effects: Provides graphics pointing device interrupt handling. -- 
το! Modifies: Status Mode, and μουβε Buffer X-Y positions are updated. -- 


++{ Requires: Runtime initialization of interrupt vector. -- 
--] Raises: Task will terminate on MOUSE_ERROR. =< 
*-| Engineer: M. Sperry. os 
“τ Date 3 9-30-88 

-- Purpose : 


το Package Mouse provides one task and one procedure. The procedure 

-- Initialization sets up the mouse at 4800 baud, no parity, 7 data bits, and 
τι two stop bits. The number of stop bits is insignificant. There should 

-- only be two formats that the mouse can be in, either relative bit pad one 
-- or Micrsoft Mouse. The default on power up for the mouse is MM at 4800. 

++ The mouse must be commanded in the following order: BAUD (which js set to 
-- default to 4800 so it jis not necessary to reprogram it), # of reports/sec., 
το and then format of the reports. 


with Types; 

with Low _Level_10; 

with Debug 10; 

with Mouse Buffer; 

with Mouse Data; στ provides constants and data structures 
with Status; 

with Interrupt_Controt; 

with Time_Stamp; 

use Low_Level_10; 

use Mouse_Data; -+ visibility to "end" function 


Pragma ELABORATE(Low_Level_10, Debug_!0, Mouse Buffer, Status, Time Stamp); 
package body Mouse is 


OATA : Low_Level_10.8YTE; -- char from mouse 


BUTTON_PUSHED : Mouse_Data.BIT_FIELD; ++ array representing keys 
STATUS_BYTE : Mouse_Data.BIT_FIELD; -- represents status errors 
PREV_BUTTON_PUSH : Mouse _Data.BIT_FIELO := (others => FALSE); --previous buttons 
MOUSE _ INPUT : Mouse_Data.RAW_MOUSE WORD :* (0,0,0);-- transform to 12-bit 
MOUSE _REPORT : Mouse_Data.SIGNED_MOUSE_WORD; -- transformation to signed 
REPORT _COUNT : Types.WORO range 0..5 :=2 0;  -- counts byte jn report 
CHANGE REQUESTED : BOOLEAN := FALSE; ττ rendezvous with status? 
MOUSE _ERROR : EXCEPTION; 

TEMP_X s Types WORD; -- local copy of X motion 
TEMP_Y s Types.WORD; °- local copy of Y motion 


procedure Initialize is 
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-- A procedure used to initialize the mouse to 4800 baud and Relative Sit 
-- Pad One format. 


INTERRUPTS : Low _Level_!0.8YTE; ++ for input of 8259 ints 
RESPONSE =: Low_Level_!0.BYTE: -- for mouse responses 
TIME_OUT : INTEGER := 30000; ~- time out for mouse response 
begin 


Receive _Controi (Mouse_Data.COM2_status,RESPONSE); -- clean out junk in status 
Receive Control (Mouse_Data.COM2_data, RESPONSE); στ clean out junk in data 
Send_Control (Mouse_Dats.COM2_control ,Mouse_Data.access_beud); 
Send_Control (Mouse_Data.COM2_data,Mouse_Data.host_baud); -- set BAUD = 4800 
-- set COM2 serial parameters 
Send_Control (Mouse_Data.COM2_control ,Mouse_Data.host_format); 
Send_Control (Mouse_Data.COM2_data,Mouse_Data.acknowledge); -- touch mouse 
loop P 
Receive Control (Mouse Data.COM2_status,RESPONSE); -- wait for response 
if RESPONSE = Mouse_Data.data_new then 
Receive_Control(Mouse_Data.COM2_ data,RESPONSE); -- clear out byte 
exit; 
eise 
TIME_OUT := TIME QUT - 1; 
end if; 
if TIME_OUT = 0 then 
exit; 
end if; 
end loop; 
if TIME_OUT = 0 then 
Debug. 10.Put_Line("Unable to establish communications with mouse."); 
end if; 
Send_Control (Mouse_Data.COM2_data,Mouse_Data.mouse_char_speed); 
delay 0.01; -- slow for mouse input buffer 
Send_Controt (Mouse_Data.COM2_data,Mouse_Data.mouse_formet); 
Send_Control (Mouse _Date.COM2_modem_controt ,Mouse_Data.general_int_enable); 
Send_Control (Mouse Data.COM2_int_enable,Mouse_Data.specific_int_enabie); 
Receive_Control (Mouse_Data.pic_8259_mr, INTERRUPTS); 
*- enable COM2 in PIC ἴω Line below 
INTERRUPTS :2 Mouse_Data.Bits_to Byte 
(Mouse _Data.Syte_to BitsC INTERRUPTS) and Mouse_Oata.pic_and_mesk); 
Send_Control (Mouse_Data.pic_8259_mr, INTERRUPTS); 
end Initialize: 


task body Char_in is 


+> One of the main tasks used to move the reticle around the battlefield screen. 
++ The task rendezvous with the graphics task reporting positions every 28 

-- milliseconds, unless the middle button is pressed (mode) changing the mode 
+> to AUTOMATIC. In this event, the mouse simply waits for ὁ change to 

τα MANUAL, since autometic mode is controlled by the rocket task. The mouse 


-123- 


Demonstration Project Final Report 


> task will not rendezvous with the graphics task until set to MANUAL. When 
++ fm MANUAL mode, the task (upon completion of one report) will rendezvous 
-- with the graphics task at high priority to report it’s position. It wilt 
-+ then change the status task’s shared variables if any need to be changed. 
στ If ome does, and the status task has compieted it’s previous work and gone 
-- to an accept state, then the mouse task wakes it up. 


use Status; “- for visibility to “=” 
use Types; -- for visibility to “+ 
begin 
loop 
accept Report do 
Interrupt_Control.Clear_Direction_Flag; τ (RTE bug) 


+-$TP(0056) Mouse task start 
Receive _Control (Mouse Data.COM2_status,DATA); -- receive status 
STATUS BYTE := Mouse Data.Syte_to_Bits(DATA);--check statusbyte for errors 
if STATUS_BYTE(Mouse _Data.overflow) or 
STATUS_BYTE(Mouse_Data. framing) then 


REPORT _COUNT := 0; τ start a new report 
Receive_Control (Mouse _Data.COM2_data,DATA); -- clear out data port 
else 
Receive Control (Mouse _Data.COM2_data,DATA); -- get valid data 
if DATA > Mouse_Data.sync_byte then το check for new report 
REPORT_COUNT := 1; στ start of new report 
end if; 
end if; 
case REPORT_COUNT is -- convert data to mouse X,Y 
when 1 => -- or buttons. 


RUTTON_PUSHED := Mouse_Data.Syte_to_Bits(DATA); 
REPORT_COUNT := REPORT_COUNT + 1; 
when 2 => 
MOUSE_INPUT.LOW := Mouse Data.Byte_to_Bit6(DATA); 
REPORT_COUNT := REPORT_COUNT + 1; 
when 3 => 
MOUSE_INPUT.HIGH := Mouse Date.Byte_to Bit6(DATA); 
MOUSE_REPORT := Mouse _Data.Raw_to_Signed(MOUSE INPUT); 
TEMP_X := MOUSE REPORT .LOW12; 
REPORT _COUNT := REPORT COUNT + 1; 
when 4 s> 
MOUSE_INPUT.LOW :5 Mouse Data.Byte_to_Bit6(DATA); 
REPORT _COUNT := REPORT COUNT + 1; 
when 5 => 
-- don’t move mouse if any buttons pushed. 
if (not BUTTON_PUSHED(Mouse_Deta.reset)) and -- guarantee only one - 
(mot BUTTON_PUSHED(Mouse Data.mode)) and -- rendezvous per report- 
(not BUTTON _PUSHED(Mouse Data.launch)) then -- (RTE bug) - 
PREV_BUTTON_PUSH(Mouse Data.reset) <= FALSE; 
PREV_BUTTON_PUSH(Mouse_Data.mode) :5 FALSE; 
PREV_BUTTON_PUSH(Mouse_Data.launch) := FALSE; 
MOUSE_INPUT.HIGH :# Mouse Data.Byte_to_ Bité(DATA); 
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MOUSE_REPORT := Mouse Data.Raw_to_SignedsMOUSE INPUT); 
TEMP_Y :π MOUSE REPORT .LOW12; 
if Status.MODE = Status.MANUAL then 
MOUSE_SUFFER.MOUSE_X := TEMP_X; 
MOUSE_BUFFER.MOUSE_Y := TEMP_Y; 
-*$TP(0057) Mouse rendezvous with Seve start 
select +> must be conditional to work in INTERRUPT HANDLER 
. . Mouse_Buf fer. Save Reticle Motion; 
-*$TP(0058) Mouse rendezvous with Save end 
else 
oo: Xe raise MOUSE ERROR; 
end select; 
end if; 
else 
tf BUTTON_PUSHED(Mouse_Data.reset) and 
ποῖ PREV_BUTTON_PUSH(Mouse_Data.reset) then 
for 1 in Status.RESET_STATUS_TYPE loop 
Status.STATUS_CONTROL(3).DATA :5 0; 
“Status .STATUS_CONTROL(1).DISPLAYED := FALSE; 
end loop; 
Status .REQ_COUNT := Status.REQ COUNT + 1; 
CHANGE_REQUESTED := TRUE; 
PREV_BUTTON_PUSH(Mouse Data.reset) := TRUE; 
else 
if mot BUTTON_PUSHED(Mouse_Dats.reset) then 
PREV_BUTTON_PUSH(Mouse_Data.reset) := FALSE; 
end if; 
end if; 
if BUTTON_PUSHED(Mouse_Data.mode) and 
Mot PREV_BUTTON_PUSH(Mouse Data.mode) then 
if Status.MOOE = Status.MANUAL then 
Status.MODE := Status. AUTOMATIC; 
else 
Status.MODE :- Status.MANUAL; 
erd if; 
Status .MOOE_DISPLAYED := FALSE; 
Status.REQ_COUNT := Status.REQ_COUNT + 1; 
CHANGE _REQUESTED :5 TRUE; 
PREV_BUTTON_PUSH(Mouse_Dats.mode) :5 TRUE; 
else 
if not BUTTON PUSHED (Mouse Data.mode) then 
PREV_BUTTON_PUSH(Mouse_Data.mode) :: FALSE; 
end if; 
end if; 
if BUTTON PUSHED (Mouse_Data. launch) and 
Mot PREV_BUTTON_PUSH(Mouse_Deta.launch) then 
if Status.MODE = Status.MANUAL then 
Mouse_Buffer.LAUNCH := TRUE; 
Mouse_Buf fer .NEW_ABS_X := Mouse_Buffer.OLD_A8S_X; 
Mouse_Suffer.NEW_ASS_Y :5 Mouse _Suffer.OLD_ABS_Y; 
end if; 
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PREV_BUTTON_PUSH(Mouse_Data.launch) := TRUE; 


else 
if not BUTTON_PUSHED (Mouse_Data. Launch) then 


PREV_BUTTON_PUSH(Mouse_Data. launch) ss FALSE; 
end if; 
end if; 
if CHANGE_REQUESTED and then Status.REQ_COUNT 5 1 then 
»-$TP(0059) Mouse rendezvous with Status start 
select 


Status.Update. Signal; 
--$TP(0060) Mouse rendezvous with Status end 


else 
raise MOUSE ERROR; 
end select; 
end if; 
end if; 
CHANGE REQUESTED := FALSE; 
REPORT COUNT := 0; 
when others => null; 
end case: 
Send_Control (Mouse_Data.pic_8259,Mouse_Data.spec_edi ); -- specific Eol 
--$7P(0061) Mouse task end 
end Report; 
end loop; 
exception 
when others 2> 
Debug_!0.Put_Line "Error in Char_in Task"); 
Send_Control (Mouse_Data.pic_8259, Mouse_Data.spec_eoi); 
raise; 
end Char_in; 


end Mouse; 
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--| UNIT: Mouse_Buffer Package Spec. εἰν 
--| Effects: Suffers mouse data input, translates it to pixel system. “- 
στ Modifies: No global data is modified (other than fin own spec). “- 
“:- Requires: No initialization is required. “- 
5 Raises: No explicitly raised exceptions are propagated. -- 
σ:͵ὶ,ὶ Engineer: M. Sperry. oo 


--“..». eeecescoeaesveosne wonere ww eeeeceawcvcasesevecoccoce weeenaseeworsese -..- 


-- Date : 10-24-88 

+- Purpose : 

το Package Mouse Buffer contains a task called Save which is responsible for 
σι saving reports of mouse movement via ἃ rendezvous with δὴ interrupt task. 
στ The task then rendezvous with the display task to relocate the reticle. 


with Types; 
with Config; 


package Mouse Buffer is 
stack_size : constant := 118; -- in bytes 
MOUSE_X Types. WORD; στ for use with the Save task in Mouse Buffer 


MOUSE_Y : Types .WORD; στ for use with the Save task in Mouse Suffer 
LAUNCH s BOOLEAN := FALSE; 


OLD_ABS_X : Types.WORD; τ absolute X position of Reticle on Screen 
OLD_ABS_Y : Types.WORD; ἊΡ * Y ᾿ " " 
NEW_ABS_X : Types.WORD; τ. for use by ENGAGE (latched values by Mouse pkg) 
NEW_ABS_Y =: Types.WORO; 


task type Save_Type is 
entry Reticle Motion; 
pragma PRIORITY(Config.save_priority); 
end Save_Type; 
for Save_Type’STORAGE_SIZE use INTEGER(Config.bytes_per_storage unit * 
stack_size); 
Save : Save_Type; -- for saving motion of mouse to display 


end Mouse_Buffer; 
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ΟΣ ΣΧ “--.... Oe ee ee er eee) 


΄ 


++] UNIT: Mouse_Buffer Package Body. “- 
“Ὁ Effects: Buffers mouse data input, translates it to pixel system. -- 
“τ Modifies: No global data is modified (other than in own spec). -- 
5. Requires: No initialization is required. -- 
--| Raises: No explicitly raised exceptions are propagated. -- 
Ὁ Engineer: M. Sperry. ᾿Ξ 


ΟΣ ΧΧ ΣΧ, “-.“-... ““.-.-.-“...«- “-..-.-.. Redecccecvesacccesvescose ΣΧ ΣΧ Χ 


+> Date : 10-24-88 
-- Purpose : - 

στ Package body Mouse Buffer is responsible for the implementation of the 
-- buffering between the mouse interrupt routine and the screen. Note that 
-- checks ere performed to be sure that the reticle is within the screen 

+- defined by Config. Also, note that the Y coordinate is reversed because 
στ the screen on the EGA runs (in the Y direction) from 0 to 349 starting 
-- from the upper left and moving down, i.e., the mouse has Y direction as 
στ positive moving up, and the EGA has positive moving down. 


with Shapes; 

with Graphics; 

with Config; 

with Debug 10; 

with Interrupt_Control; 

with Time_Stamp; 

pragma ELABORATE(Debug_I0, Graphics, Interrupt_Control, Time_Stamp); 


package body Mouse_Buffer is 

use Types; +> needed for visibility to ‘+! 
task body Save_Type is 

List_len s constant :# 1; 


teft_limit constant :5 Config.bettlefield_screen_left; 


right_limit : constant := Config.battlefield_screen_right; 

top_limit : constant :* Config.battlefield_screen_top; 

bottom _limit : constant := Config.battlefield_screen_bottom; 

PRIORITY : Graphics.PRIORITY_TYPE := Graphics.HIGH; 

WORK_LIST : Graphics.MOVE_LIST_TYPE(List_len .. list_len);-- 1 item (reticle) 
TEMP_X : Types. WORD; 

TEMP_Y : Types .WORD; 

begin 


-- Initial display of reticle 
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WORK_LIST(tist_(en).XY_OLD := (Config.battlefield_center_x, Config.bettlefield_center_y); 
WORK_LIST(lList_len).XY_NEW := (Config.battlefield_center_x, Config.bettlefield_center_y); 
WORK_LIST(lList_len) OBJECT := (Shapes.PIXEL_MODE , Shapes RETICLE); 
WORK_LIST(List_lem).COLOR :π Graphics.reticle_color; 


Graphics .Display.Move(PRIORITY, WORK_LIST); 


loop 
begin -- exception block 


--$TP(0062) Mouse Buffer task and accept 
accept Reticle Motion; 


Get new positions of reticle (mouse) 


Interrupt_Control .Disable; 

TEMP_X := WORK_LIST(List_len).XY_OLD.X + MOUSE_X; 
TEMP_Y := WORK_LIST(List_len).XY_OLD.Y - MOUSE_Y; 
Interrupt_Control .Enable; 


Check bounds of reticle; don’t let it go past edge of screen. 


if (TEMP_X + Shapes.RETICLE LEFT) < left_timit then 
TEMP_X := left_limit - Shapes.RETICLE LEFT; 

elsif (TEMP_X + Shapes.RETICLE RIGHT) > right_limit then 
TEMP_X-:2 right_limit - Shapes.RETICLE_RIGHT; 

end if; 

if (TEMP_Y + Shapes.RETICLE_TOP) < top_limit then 
TEMP_Y :π top_limit - shapes.reticle_top; 

elsif (TEMP_Y + Shapes.RETICLE BOTTOM) > bottom_limit then 
TEMP_Y := bottom_limit - Shapes.RETICLE_ BOTTOM; 

end if; 


WORK_LIST(List_lenm).XY_NEW.X :Ξ TEMP_X; 
WORK_LIST(List_len).XY_NEW.Y := TEMP_Y; 


update global accessable values 


Interrupt_Control Disable; 
OLD_ABS_X := TEMP_X; 
OLD_AGS_Y := TEMP_Y; 
Interrupt_Control .Enable; 


--$TP(0063) Mouse_Buffer rendezvous with Graphics start 
Graphics .Display.Move(PRIORITY, WORK_LIST); 
--$TP(0064) Mouse_Buffer rendezvous with Graphics end 


WORK_LISTCList_len).XY_OLD := WORK_LIST(List_len).XY_NEW; 


exception 
when others 5» 
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Debug_!0.Put_Line("Error in Save"); 
end; -- exception block 


=-$TP(0065) Mouse_Suffer task end 
end loop; 


end Save_Type; 


end Mouse Buffer; 
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Se PSO M eT eTOweseerreaseeveweeseserevecseeevesessiusesevesesesessesevesceereces - 


κε UNIT: RDL Package Body Subunit. “- 
--| Effects: Supports all Rocket Data Link functions of Simulator. -- 
5: Modifies: No global data is modified. 535: 
στ Requires: No initialization is required. “= 
--| Raises: No explicitly raised exceptions are propagated. “- 
5: Engineer: 1. Griest. od 


wevesseue ΟΣ weoconece ecesneacecccoesecs aesesacce «“.---.... 


-+ The RDL package provides tasks to interface to the Rocket Data Link 
-+ fssuing messages for new rocket positions and receiving messages 
-- commanding new rocket attitudes. 


separate(Simulate) 
package body ROL is τ Rocket Data Link Simulator 


΄ 


stack_size : constant := 348; 


task type Rock Sup_Type is 
pragma PRIORITY(Config.rock_sup priority); 
end Rock_Sup_Type; 
for Rock_Sup_Type’STORAGE_SIZE use INTEGER(Config.bytes_per_storage_unit * 


stack_size); 
Rock_Sup : Rock_Sup_Type; 
task body Rock_Sup_Type is separate; 
task body Report_Buf Type is separate; 
task body Guide_Buf_Type is separate; 
end ROL; 
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Pes eseewaeernecwetvecenesnvessceenstoessesesesees “--...- woeteocccucncce wees 


o-| UNIT: Report_Buf Task Body Subunit. 


o-] Effects: 


++] Modifies: Wo global data is modified. 
τι. Requires: No initialization is required. 


--( Raises: 


σε. Engineer: T. Griest. 


«“-.-..- ΟΣ ΧΧ ΣΧ. “.“.-......- weet eseensrcacace «“.-.-.- weawceccoversoces 


Wo explicitly raised exceptions are propagated. 


Buffers Rocket report data between simulator and Control. -- 


The Report_Buf task acts es a buffer between the rocket data link 
support task Rock Sup and the Rocket.Contral task which processes 


the rocket data. 


TIMING CONSIDERATIONS: Report _Buf wil! only provide the most recent 
message received. If two messages are received prior to one being 


taken, the first will be lost. 


΄ 


with Debug_I0; 
with Time_Stamp; 
pragma ELABORATE(Debug_!0, Time_Stamp); 


separate (Simulate.ROL) 


task body Report_Buf_Type is 


use Types; 
ROCKET_MSG s Rocket. ROCKET_MSG_TYPE; 


begin 


ROCKET _MSG.NUM_ROCKETS :# 0; -- default 
loop 


select 


accept Put_Report(DATA : im Rocket ROCKET _MSG TYPE) do 


--$TP(0066) Report_Buf accept Put_Report start 
ROCKET_MSG.NUM_ROCKETS := DATA.NUM_ROCKETS; 


κ᾿ copy data 


for ἴ im Types.WORD_INDEX range 1..DATA.NUM_ROCKETS loop 


ROCKET _MSG.ROCKET_LIST(I) :# DATA.ROCKET_LIST(I); 
end loop; 
--$TP(0067) Report_Buf accept Put_Report end 
end Put_Report; 
or 


accept Get_Report(DATA : out Rocket .ROCKET_MSG_ TYPE) do 


--$TP(0068) Report_Buf accept Get_Report start 
OATA.NUM_ROCKETS := ROCKET _MSG.NUM_ROCKETS; 


for 1 in Types. WORD_INDEX range 1..ROCKET_MSG.NUM_ROCKETS loop 


DATA.ROCKET_LISTC(1) := ROCKET _MSG.ROCKET _LIST(1); 
end loop; 
+-STP(0069) Report_Buf accept Get_Report end 
end Get_Report; 
end select; 


end loop; 
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exception 
when others => 
Debug_!0.Put_L ine("REPORT_BUF termination due to exception."); 


end Report suf _Type; 
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“.....- - ον οσοσ στ σα 5..5. wee cwacenrerccncces weeecccornecctosecencesce weorceccee 


ΖΕ UNIT: Rocket Package Spec. - ad 
55] Effects: Provides structure for Rocket managment within 805. “- 
στ Modifies: No global data is modified. += 
51 Requires: No initialization is requi-cd. 5.5. 
το Raises: No explicitly raised exceptions are propagated. -- 
--| Engineer: T. Griest. ἰὼν 


“οοτσοσοσοσσσοο. σ 595 weeecenenecescces wewcceerarecscerecoese “-..... -“-“-.“.55..5.-. 


c+ The Rocket package provides all processing to maintain the rockets 
s+ in flight. 


with Types; 
with Config; 


Package Rocket is 


stack_size . : constant := 1936; -- in bytes 
πὸ REPORT INFORMATION se 
type ROCKET_ITEM_TYPE is record --| provides essentials on a rocket 
TIME_TAG : Types .WORD; 
ROCKET_ID : Types.WORD_INDEX; 
POSITION : Types .POSITION_TYPE; 
end record; 
type ROCKET_LIST_TYPE is στ] List of all rocket data 


array(Types.WORD_{NDEX range <>) of ROCKET _ITEM_TYPE; 


type ROCKET _MSG_TYPE is record 

NUM_ROCKETS : Types. WORD_ INDEX; 

ROCKET_LIST : ROCKET_LIST_TYPE(1. .Config.max_rockets); 
end record; 


ἜΧΩ .5-..-..-- weoceeereosace “.“---.-.- ee 


5 GUIOANCE INFORMATION 5.5 


weeescucacce ΟΣ “..-..-.--- we 


type ROCKET_GUIDE_TYPE is record 


ROCKET _ID 2 Types.WORD_INOEX; | 
AIMPOINT 2 Types .AIMPOINT TYPE; 
end record; 


type ROCKET _GUIDE_LIST_TYPE is “τ List of all guidance data 
array(Types.WORD_INDEX range <>) of ROCKET _GUIDE_TYPE; 


type ROCKET _GUIDE_MSG_TYPE {is record 
WUM_ROCKETS : Types .WORD_INOEX; 
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. 


ROCKET_GUIDE_LIST 2 ROCKET_GUIDE_LIST_TYPE(1..Config.max_rockets); 
end record; 


went woes Sree cece weeeesoneretenes © Leet essevaacesesccesccoucreeestasseoesasecocsos 


task type Control_Type is “:-| for overall engagement control 
entry Get_Next_Report (ROCKET _REPORT_MSG : im ROCKET_MSG_TYPE); 
pragma PRIORI TY(Config.control_priority);: 

end Control_Type; 

for Control_Type’STORAGE_SIZE use INTEGER(Config.bytes_per_storage_unit * 


stack size); 
Control : Control_Type; 


end Rocket; τ- package specification 
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co] UNITS Rocket Package Body. τ 
--| Effecte: Provides structure for Rocket managment within Β05. “- 
“:-] Modifies: No global data is modified. -- 
-:1 Requires: No initialization is required. sare 
“1: Raises: No explicitly raised exceptions are propagated. -- 
τοῦ Engineer: T. Griest. -- 


τ The Rocket package provides all processing to maintain the rockets 
-- im flight. 


with Debug _ 10; 


with Status; -- maintains number Rockets Active 
with Shapes; -- for rocket shapes 
with Graphics; -- for graphics operations/colors 


with Distrib; - 
pragma ELABORATE(Debug_!0, Status, Graphics); 


package body Rocket is 


guidance_stack_size : constant := 660; 


-- The rocket guidance activity is given overall control by the Control task. 
-- “Control" is used to accept rocket reports, and is responsible for engaging 
“> the targets, providing updates to the Graphics.Dispiay task, and generating 
-- the guidance messages for the Rocket Data Link. It achieves much of this 
-- with the assistance of one (or more) Guidance task(s). The Guidance task 
-- is responsible for taking a set of the rockets and producing ὃ new 

τ gimpoint for each rocket/target in that set. The activities of the 

-- guidance task(s), as well as the Control task can be overlapped 

-- considerably, and therefore may benefit from the addition of processors. 


GUIDANCE_LIST_ERROR : exception; -- if guidance List does not match history 


-- This history data is provided to a guidance task, which in turn processes 
-* ft and returns the next guidance information needed for each rocket. 


type HISTORY_DATA_TYPE is record “τ containing rocket information 
ACTIVE : BOOLEAN; “τ if rocket was previously active 
TARGET 3 Types.WORD_INDEX; --| rocket’s target 
POSITION _PAIR : Types.POSITION_PAIR_TYPE; 


end record; 


type HISTORY_LIST_TYPE is 
array(Types.WORD_INDEX range <>) of HISTORY _DATA_TYPE; 
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type AIMPOINT_LIST_TYPE ts Ξ 
array(Types.WORD_INDEX range <>) of Types .AIMPOINT_TYPE; 

ROCKET_HISTORY : HISTORY_LIST_TYPE(1. .Config.max_rockets); 
WEXT_GUIDE_MSG : ROCKET_GUIDE_MSG_TYPE; 
task type Guidance_Type is 

entry History(HISTORY_DATA : in HISTORY_LIST_TYPE); 

entry Next_Guidance(AIMPOINT_LIST : out AIMPOINT _LIST_TYPE); 

pragma PRIORITY (Config. guidance_priority); 
end Guidance_Type; 
for Guidance_Type’ STORAGE_SIZE use INTEGER(Config.bytes_per_storage_unit * 


quidance_stack_size); 


Rocket_Guide : array(Types.WORD_INDEX range 1. .Distrib.mum_guide_tasks) 
of Guidance_Type; 


task body Guidance_Type is separate; 
task body Control_Type is separate; 


end Rocket; -- package body 


-137- 


Demonstration Project Final Report 


SOROS Me MPSS SKS SSS SSE SHS SESH HOSSSHSTOHRSTM SESS SSSA OTP TE SSSeSZesewaesertaesesesezses | 


o-] UNIT: Rock_Sup Task Sody Subunit. - “- 
--| Effects: Provides all Rocket Support for Simulator, including -- 
5,5] ᾿ target intercept detection. “- 
-+| Modifies: Updates state of rockets and targets in Simulator Ὁ8886. “- 
στ Requires: No initialization is required. -- 
το. Raises: No explicitly raised exceptions are propagated. =< 
55} Engineer: T. Griest. “- 
-- ROCK_SUP Ἰδὲεκ Body ἘΞ 


-- The rocket support task provides the necessary rocket motion, based 

“τ on previous position and the application of a new guidance aimpoint. 

το It generates 8 new report “ROCKET_MSG" for a buffer task (Report_Buy) 

στ to forward to the SDS Rocket.Control task. Likewise, the Rocket.Control 
.c+ task issues guidance messages to the buffer task (Guide _Suf) which are 
-- made available to the Rock _Sup task. ROCKET/TARGET intercepts are 

-- checked in the shared data base within the simulator. In such cases, 

-- both the rocket and target are destroyed (marked inactive). 


-+ Copyright(C) 1988, LabTek Corporation. Permission is granted to copy 

στ and/or use this software provided that this copyright notice is included 
~- and all Liability for its use is acce” .ed by the user. 

with Traject; “- trajectory planner 

with Calendar; 

with Interrupt_Control; 

with Time_Stamp; 

pragma ELABORATE(Traject, Calendar, [nterrupt_Control, Time_Stamp); 


separate (Simulate.ROL) 


“task body Rock_Sup_Type is 


use Calendar; -- for - operator 
use Types; -- for operators 
start_position : constant Types.POSITION_TYPE := 


(Config.meters_in_battle_aresa/2.0,60.0,0.0); 


ROCKET _MSG : Rocket .ROCKET_MSG_TYPE; 

GUIDE _MSG 2 Rocket ROCKET GUIDE_MSG TYPE; 
GUIDE _MSG_ INDEX : Types.WORD_INDEX; 

REPORT _MSG_INDEX : Types .WORO_INDEX; 

POSITION : Types.POSITION_TYPE; -- temp 
TIME_TAG 3 Types.WORD := 0; 

START _TIME : Calendar. TIME; 

DELAY _PERIOO s DURATION; 


τ, MAKE REPORT: process current rocket ID 
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΄ 


procedure Make_Report(ID : Types.WORD_INDEX; POS : Types.POSITION_TYPE) is 
e+] checks if rocket has collided with 
στὸ, any targets or ground. If so, delete 
τ] target(s) and rocket. 


OELTA_X : Types.METERS; 
DELTA_Y 2 Types METERS; 
DELTA_Z : Types METERS; 
DELTA_T s Types.LONG FIXED; -- time for rocket to reach ground 
ROCKET_POS : Types.POSITION TYPE; 
begin -- of Make Report 


--$TP(0070) Rock _Sup.Make Report start 
if POS.z < 0.0 then 
ROCKETS(1D) ACTIVE := FALSE; -~ destroy rocket 


=> compute time it toek to get to zero 
OELTA_X :% POS.X - ROCKETS(ID).POSITION.X; 
DELTA_Y :# POS.Y - ROCKETS(ID).POSITION.Y; 
DELTA_2 := POS.2 - ROCKETS(1D).POSITION.Z; 


if DELTA_Z = 0.0 then 
DELTA_T := 0.0; 
else 
DELTA_T := Types. LONG_FIXED(ROCKETS(ID).POSITION.2/abs(DELTA_2Z)); 
end if; 
-- find terminal position of Rocket 
ROCKET_POS.X :2 ROCKETS(10).POSITION.X + Types. METERS(DELTA_T*DELTA_X); 
ROCKET_POS.Y :* ROCKETS(ID).POSITION.Y * Types. METERS(DELTA_T*DELTA_Y); 
--TBO since targets are slways at 220, collision point is always 0 
-- ROCKET_POS.Z := ROCKETS(10).POSITION.Z + Types.METERSCDELTA_T*DELTA_2); 


-- Now search target list to see if any targets within "kill_redius" 
“- perimeter of rocket 


for TARGET_IO im TARGETS’range loop 
Interrupt_Control Disable; -- access to shared data 
{f TARGETSC(TARGET_ID).ACTIVE then 
DELTA_X :- ROCKET_POS.X - TARGETS(TARGET_1D).POSITIOW.X; 
DELTA_Y :* ROCKET _POS.Y - TARGETS(TARGET_ID).POSITION.Y; 
--(80 should use distance DISTANCE :* Math.Sart( Types. METERS(DELTA_X*DELTA_X) + 


--TBO Types .METERS(DELTA_Y*DELTA_Y) + 
--T80 Types .METERS(DELTA_2*DELTA_2))); 
if abs OELTA_X < Config.kill_readius and -- this makes square box 
abs OELTALY < Config.kill_radius στ around each target 
then 
TARGETSCTARGET_1D). ACTIVE := FALSE; -- destroy target 
end if; 
end if; 
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Interrupt_Control .Enable; 
end loop; τ 


else =- Rocket did not hit ground or target 


REPORT_MSG_INDEX := REPORT_MSG_INDEX + 1; 
ROCKET_MSG.ROCKET_LIST(REPORT_MSG_INDEX) := (TiME_TAG,1D,POS); 
end if; 
-*$TP(0071) Rock_Sup.Make_Report end 


end Make Report; 


ROCKET SUPPORT TASK BODY “- 
begin 
for 10 in ROCKETS’range loop -- initialize to all finective 
ROCKETS(ID) ACTIVE := FALSE; 
end loop; 
START_TIME :- Calendar .CLOCK; -- find out when xeq begins 
Loop 


*-$TP(0072) Rock_Sup task start 
START_TIME := START_TIME + Config. interval; 


if TIME_TAG = Types.WORD’ last then -- update TIME_TAG to be able 
TIME_TAG :Ξ 0; -- to differentiate between 

else . -- stale and new reports 
TIME_TAG := TIME_TAG « 1; 

end if; 


*°$TP(0073) Rock Sup rendezvous with Guide Buf start 
ROL .Guide_Buf .Get_Guide(GUIDE_MSG); -- fetch latest guidance message 
~°$TP(00746) Rock_Sup rendezvous with Guide_Buf end 


Go through each rocket, and if active, apply trajectory to 
current position for 1 interval. 


GUIDE_MSG_INOEX := 1; ++ pointer mag.rocket_guide_list 
REPORT _MSG_INOEX := 0; 
for ROCKET_ID im ROCKETS’ range loop 
if GUIDE_MSG_INDEX <= GUIDE _MSG.NUM_ROCKETS and then 
ROCKET_[0 = GUIDE_MSG.ROCKET_GUIDE_LIST(GUIDE_MSG_INDEX).ROCKET_ID 
then 


This rocket is in the list, see if it was previously active 
ff not ROCKETS(ROCKET_ID).ACTIVE then 


filter out guidance messages for rockets that have recently been 
destroyed (but BOS doesn’t know it yet) 


{f GUIDE_MSG.ROCKET_GUIDE_LIST(GUIDE_MSG_IMOEX) .AIMPOINT ELEVATION = 16384 


then -- 8 new leunch 
ROCKETS(CROCKET_[0).ACTIVE := TRUE; -- launch 
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ROCKETS(ROCKET_ID).POSITION := start_position; 
Make_Report(ROCKET_ID,start_position); -- start δὶ leuncher 
end if; 
eise 


-- Now compute new X,Y,Z position. 


POSITION := Traject( ROCKETSCROCKET_!D).POSITION, 
GUIDE_MSG.ROCKET_GUIDE_LIST(GUIDE_MSG_INDEX) .AIMPOINT); 

Make_Report(ROCKET_ID, POSITION); 

ROCKETS(ROCKET_ID) POSITION :5 POSITION; 


end if; -- rocket active check 
GUIDE_MSG_INOEX := GUIDE_MSG_INOEX + 1; 
else -- mo guidance for this rocket 


if ROCKETS(ROCKET_ID).ACTIVE then 
-- ὁ guidance information for active rocket, simply don’t move it 


POSITION := ROCKETS(ROCKET_ID).POSITION; 
Make_Report(ROCKET_ID POSITION); 


end if; “- rocket active check 
end if: -- guide entry exists check 
end loop; 


4. New report list has been generated. Send it to buffer task. 


ROCKET_HSG.NUM_ROCKETS := KEPORT_MSG_INDEX; 

-*$TP(0075) Rock Sup rendezvous with Report_Buf start 

RDL .Report_Buf .Puc_Report(ROCKET_MSG); τ. issue next rocket report 
--$TP(0076) Rock_Sup rendezvous with Report_Buf end 


-- Delay to make rocket motion reports periodic 


DELAY_PERIOO := START_TIME - Calendar .CLOCK; 
if DELAY_PERIOO < 0.0 then 
START_TIME :2 CLOCK; 

end if; 
--$T7P(0077) Rock_Sup task end 
delay DELAY_PERICO; 

end loop; 

end Rock_Sup_Type; 
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OR weed ee wm mwmet saeco esas στ sen asssceteceeveseenosiearecessesreses eewseccoe eocuece 


e+] UNIT: Shapes Package Spec. . -- 
“5} Effects: Provides all graphics symbology. -- 
«=| Modifies: No globai data is modified. “- 
“>| Requires: No initialization is required. τὰ 
--| Raises: No explicitly raised exceptions sre propagated. “- 
510 Engineer: T. Griest / M. Sperry. “- 
“- SHAPES PACKAGE SPECIFICATION -- 

“τ Date : 10-12-88 ᾿ 

++ Purpose : 


-- Package Shapes is responsible for determining the shapes of the various 
-* symbols. 


with Types; Ἐ 
with Config; 


package Shapes is 


type SYMBOL_TYPE is (ROCKET, TARGET, RETICLE, DOT, ZERO, ONE, TWO, THREE, FOUR, 
FIVE, SIX, SEVEN, EIGHT, NINE, HORIZONTAL, VERTICAL); 


type OBJECT_MODE_TYPE is (TEXT_MODE, PIXEL_MODE); 


type PIXEL is record 

X:Types.COORDINATE range Config.entire_screen_left..Config.entire_screen_right; 
Y:Types.COOROINATE range Config.entire_screen_top. .Config.entire_screen_bottom; 
end record; 


type REL_PIXEL is record -- offset from base of pixel 
X_OFFSET : Types.REL_COORDINATE; <> positive goes right 
Y_OFFSET : Types.REL_COORDINATE; τ positive goes down 
end record; 


type PIXEL_LIST is array(Types.WORD_INDEX range <>) of REL_PIXEL; 


type OBJECT _TYPEC(OBJECT_MODE : OBJECT_MODE_TYPE := TEXT MODE) is record 
case OBJECT MODE is 
when TEXT MODE 2> 
TEXT_OBJECT =: STRING(1..Config.stats_title_max_length); 
when PIXEL_MODE => 
PIXEL OBJECT : SYMBOL_TYPE; 
end case; 
end record; 


type OBJECT PTR is access PIXEL_LIST; 
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reticle left : constant :2 -5; -- constants used to check if 
reticle right : constant := 5; *- reticle going past screen 
reticle_top 2 constant :2 -5; >> boundaries. 


reticle bottom : constant := 5; 


“τ The following two constants determine how far the target center can 
++ be in meters from the indicated reticle center and still allow 

-- aquisition of the target for launching a rocket. They are not the 
“> same in X and Y, since the reticle fs slightly rectangular. 


reticle_x_ error: constant :* 40.25; τν METERS to allow target aquisition 
reticle _y error: constant :5 469.50; “- METERS to allow target aquisition 
NUMERIC : array(0..9) of SYMBOL_TYPE := (ZERO, OWE, TWO, THREE, FOUR, 


FIVE, SIX, SEVEN, EIGHT, NINE); 


number_width : constant :2 8; -- widest number in pixels 
OBJECT_PTR_TABLE : array(SYMBOL_TYPE) of OBJECT_PTR :2 
(TARGET => mew PIXEL_LIST’( 
(0,-2), 
(.1,:1), C1,°1), 
(-2,0), (0,0), (2,0), 
(-1,1), (1,1), 
(0,2) ), 


ROCKET => mew PIXEL _LIST’( 
(0,0), 
(0,1), 
(0,2), 
(0,3), 
(-1,2), ΚΑἸἵ,4) ), 


RETICLE => mew PIXEL_LIST’( 


(-5,°5),€-4,-5),(-3,-5), (3,-5),(4,-5),(5,-5), 
(-5,°4), (5,-4), 
(-5,°3), (0,-3), (S,-3), 
(0,-2), 
(0,-1), 
€-3,0), (-2,0), (-1,0), (0,0), (1,0), (2,0), (3,0), 
(0,1), 
(0,2), 
(-5,3), (0,3), (5,3), 
(-5,4), (5,4), 
(5,5), (-4,5),(-3,5), (3,5),(4,5),(5,5)), 


OOT => new PIXEL_LIST’( (0,0),(0,0) ), 


ZERO => mew PIXEL _LIST’( (1,-8),(2,-8),(3,-8),(4,-8),(5,-8), 
(0,-7), (6,-7), 
(0,-6), (3, -6),(6,-6), 
(0,°5), (4,°5), (6,°5), 


-143- 


ONE => new PIXEL_LIST’¢ 


TWO => new PIXEL_LIST’¢( 


Demonstration Project Final Report 


(0,-4), (3.°4), (6,-4), 
(0,-3), (2,°3), (6,-3), 
(0,-2),(1,-2), (6,-2), 
(0,-1), (6,-1), 


(1,03, (2,0), (5,0), (4,0), (5,0)), 


(4,78), 

(3,77), €4,°7), 
(4,-6), 
(4,°5), 
(4,74), 
(4,°-3), 
(ς,-2), 
(4,°1), 

(3,0), (4,0), (5,0)), 


(1,-8), (2,°8), (3,78), ¢4,-8), 
(0,°7), (5,°7), 
(5,°6), 
(4,°5), 
(3,°4), 
(2,°3), 
(1,°2), 
(0,-1), 
(0,0), (1,07), (2,0), (3,0), (4,0), (S,0)), 


THREE => new PIXEL_LIST’( (1, -8),¢2,°8),(3,-°8), 


FOUR => mew PIXEL_LIST‘’( 


FIVE => new PIXEL _LIST’( 


(0,-7), (4,°7), 

(4,-6), 

(4,°5), 
(2,°4),(3,°4), 

(4,°3), 

(6,72), 

(0,°1), (4,°1), 
(1,0), (2,0), (3,0)), 


(ς,-8), 

(3,°7),(4,-°7), 

(2,°6), (46,°6), 

(1,°5), (6,°5), 
(0,-4),(1,-4),(2,-4),(5,-4),(6,-4)͵ (5,-6), 

(4,°3), 

(4,°2), 

(4,°1), 
(3,0), (4,0), (5,09), 


(1, -8), (2, °8), (3, -82,(4,°8), (5, -8), 
(0,°7), 
(0,-6), 
(0,°5), 

(1,24), (2,24), 03, 749,04, °4), 
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(5,°3), 
(5,-2), 
(5,-1), 
(0,0), (1,0), (2,0), (3,0), (4,0), (5,09), 


SIX => new PIXEL_LIST’¢ (3,°8),¢4,-8), 
(2,°7), 
(1,-7), 

(0,-6), 
(0,-5), ¢1,°5),(2,-5),(3,°5), 
(0,-4), (4,-4), 
(0,°3), (4,°3), 
(0,-2), (4,°2), 
(0,-1), (4,°1), 


(1,0), (2,0), (3,0)), 


SEVEN => new PIXEL_LIST’¢ (1, -8), (2,-8), (3, -8),(4,-8),(5,-8), 
΄ (0,-7), (5,-7), 
(4,°6), 
(3,°5), 
(2,°4), 
(1,°3), 
(0,-2), 
«0,-1), 
(0,0)), 
EIGHT => new PIXEL_LIST’¢ (1,-8),(2,-8),(3,-8),(4,-8), 
(0,°7), (5,-7), 
(0,-5), (5,-6), 
(0,5), (5,-5), 
(1,°4),(2,-4),(3,74),04,°4), 
(0,-3), (5,°3), 
(0,-2), (5,°2), 
(0,°1), (5,°1), 


(1,0), (2,0), (3,0), (4,0)), 


NINE => new PIXEL_LIST’( (1,°8),(2,-8),(3,-8),(4,-8), 

(0,-7), (5,°7), 
(0,-6), (5,°6), 
(0,°5), (5,°5), 
(1,-6), 62,74), 03,°4),66,°49,(5,°4), 
(5,°3), 
(4,°2), 
(3,°1), 

(1,0), (2,0)), 

HORIZONTAL => new PIXEL_LIST’((0, 0),¢1, 0),(2, 0),(2, 0),(4, 0),(5, 9), 
(6, 0),(7, 0),(8, 0),(9, 0),(10,0),(11,0), 
(12,0),(13,0),(14,0),(15,0),(16,0),(17,0), 
(18,0),(19,0),(20,0),(21,0),.(22,0),(23,0), 
(24,0),(25,0),(26,0),(27,0), (28,0), (29,0), 
(ζ0,0),(31,0), (32,0), (23,0),.(34,0),(35,0), 
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(36,0), (37,0), (38,02, (39,0), (40,0),(41,0), 
(42,0), (43,0), (44,0), (45,0), (46,0),(47,0), 
(48,0), (49,0), (50,0), (51,0), (52,0),(53,0), 
(54,0), (55,0), (56,0), (57,0), (58,0), (59,0), 
(60,0), (61,0), (62,0), (63,0), (64,0),(65,0), 
(66,0), (67,0), (68,0), (69,0), (70,0),(71,0), 
(72,0), (73,0), (74,0), (75,0), (76,0) ,(77,0), 
(78,99), 

VERTICAL => new PIXEL_LIST’((O, 0),(0, 12,0, 2),€0, 39,0, 4),(0, 5), 
(0, 6),(0, 7),€0, 8),(0, 9),(0,10),(0,11), 
(0,12),(0,13),(0,14), (0, 15}}}} 


end Shapes; 
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στ] UNIT: Sensor Package Body Subunit. 2° 
στ. Effects: Provides structure for all simulator Target motion. 515 
στ Modifies: Simulator target data is updated. bared 
°-| Requires: No initialization is required. 5: 
5. Raises: No explicitly raised exceptions are propagated. “- 
το. Engineer: T. Griest. =. 


weer ees cctaecesaveetocscacoce Mme res acccwnecswescosoncescetonccectecccesce 


-- Simulator package to provide testing of 805 system 


separate(Simulate) 
package body Sensor is κι Target Sensor Simulator 


task body Targ_Sup_Type is separate; 
end Sensor; -- body 
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2 
weoeace Reem aseseseessceenceetasecsacasensacescoses ΕΣ ΣΧ ΣΧ ς“--.--.-«- “--“.-...-. 


<>] UNIT: Simulate Package Spec. - o- 
--| Effects: Provides shared data base for Simulator. -- 
--| Modifies: No global data is modified. “- 
«-{ Requires: Individual tasks are responsible for init. of globsl deta.-- 
“5 Raises: No explicitly raised exceptions are propagated. -- 
-.Ἱ] Engineer: 1. Griest. -- 


-- Simulator package to provide testing of 805 system 
with Target; 

with Rocket; 

with Syne; 

with Config; 


package Simulate is --| Overall simulation package 
package Sensor is στ Target Sensor Simulator 
stack size : constant :5 114; -- in bytes 


task type Targ_Sup Type is 
pragma PRIORITY(Config.targ_sup priority); 
entry Next_Target_Msg(Data : out Target. TARGET_MSG_ TYPE); 
entry Clock(Time : in Sync. TIME_TYPE); 
end Targ_Sup_Type; 
for Targ_Sup_Type’STORAGE_SIZE use INTEGER(Config.bytes_per_storage_unit * 


stack_size); 
Targ_Sup : Targ_Sup Type; 
end Sensor; 
package ROL js στ Rocket Data Link Simulator 
report_buf_stack_size : constant :5 302; το in bytes 
guide _buf_stack_size : constant := 744; -. in bytes 


το The Report_Buf task buffers Rocket Reports from the Rock Sup task 
-- and provides them to the Rocket.Control task 
task type Report_Buf_Type is 
pregma PRIORITY(Contig.report_buf_priority); 
entry Put_Report(DATA : im Rocket. ROCKET _MSG TYPE); 
entry Get_Report(DATA : out Rocket.ROCKET_MSG_TYPE); 
end Report_Buf_Type; 
for Report_Buf_Type’ STORAGE _SIZE use INTEGER(Config.bytes_per_storage_unit 
* report_buf_stack_size); 


Report Buf : Report_Buf_Type; 
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“> The Guide Suf task buffers new Guidance messages from the Rocket.Control 
->- task for delivery to the Rock_Sup task. 
task type Guide Buf _Type is 
pregna PRIORITY(Config.guide_buf_priority); 
entry Put_Guide(DATA : in Rocket. ROCKET _GUIDE_MSG_TYPE); 
entry Get_Guide(DATA : out Rocket .ROCKET_GUIDE_MSG_TYPE); 
end Guide_Buf_Type; 
for Guide_Buf_Type’STORAGE_SIZE use INTEGER(Config.bytes_per_storage_unit 
* guide_buf_stack_size); 
Guide Buf : Guide_Buf_Type; 


end ROL; 


end Simulate; 
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~-| UNIT: Simutate Package Body. = hd 
το. Effects: Provides shared data base for Simulator. 7: 
το Modifies: No global data is modified. -- 
+>] Requires: Individual tasks are responsible for init. of global data.-- 
--| Raises: No explicitly raised exceptions are propagated. -- 
--| Engineer: T. Griest. “- 
with Types; 


-- Simulator package to provide testing of BOS system 


package body Simulate is --| Overall simulation package 


-“.““..-.« Pwmcecctceweeetaesasaservesseveseneasssenecess 


++ TARGET DATA es 


‘eeesrwenocccace ΟΣ ΣΧ “.--“..-..- weocecoreccecae 


type TARGET _SIM_TYPE is record *-] provides individual target information 


ACTIVE : BOOLEAN; 

POSITION : Types.POSITION_TYPE; 

TARGET_CLASS : Types. TARGET_CLASS_TYPE; 
end record; 


type TARGETS TYPE is 
array(Types.WORO_INDEX range 1..Config.max_targets) of TARGET_SIM_TYPE; 


TARGETS : TARGETS_TYPE; 


“.““..-“.-..».» οσοοτο τ es cwcresoresesrewessecereeasecee 


στ ROCKET DATA <= 


type ROCKET_SIM_TYPE is record “1 provides individual rocket information 


ACTIVE : BOOLEAN; 
POSITION : Types .POSITION_TYPE; 
end record; 


type ROCKETS_TYPE is 
array(Types.WORD_INDEX range 1..Config.max_rockets) of ROCKET_SIM_TYPE; 


ROCKETS : ROCKETS _TYPE; 


package body Sensor is separate; --| Target Sensor Simul stor 
package body ROL is separate; 51 Rocket Data Link Simulator 
end Simulate; -- body 
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o>] UNIT: Status Package Spec. -- 
το} Effects: Maintains indicators and statistics on graphics display. -- 
--{ Modifies: Flags are cleared in spec. when values are displayed. -- 
--] Requires: Initialization must be signsled by main for first display.-- 
το Raises: No explicitly raised exceptions are propagated. 7 
το Engineer: M. Sperry. -. 


“.--.--.-.Ὁ Per er ς0 sede sees ewewewcascwescevaeccesccerssceescesceeencocsccscon 


-+ Date : 11-08-88 

σε Purpose : 

-- The purpose of the Status specification package is to provide visibility 
-* to the data base which holds the requests from the mouse, et. al. The 

“> requests are entered into a data table (called STATUS_CONTROL) and then 

++ the table is checked to see if any updating of the statistics needs to be 
-- done. The checking of the table is done at an atomic level to prevent 

-- the shared data from being corrupted at critical times. The commands are 
το processed from the mouse interrupt as mode first, then reset if there are 
-- two commands to perform. 


with Types; 
with Config; 


package Status is 

stack_size : constant :* 252; 

type MODE_TYPE is (AUTOMATIC,MANUAL); 

type STATUS_TYPE is (AIRBORNE, TRACKED, EXPENDED, OESTROYED); 
subtype RESET _STATUS_TYPE is STATUS_TYPE range EXPENDED. .DESTROYED; 


type STATUS_RECORD is record 


DATA : Types.WORD :* 0; -- new statistic 
DISPLAYED : BOOLEAN := FALSE; τ’ need to display 
end record; 6 


type STATUS_TYPE_ARRAY is array(STATUS_TYPE/FIRST .. STATUS_TYPELAST) of 
STATUS_RECORD; 


τ. define shared variables 


MODE : MODE_TYPE := MANUAL; 
MOOE_DISPLAYED : BOOLEAN :# FALSE; 
STATUS CONTROL : STATUS_TYPE_ARRAY; 
REQ_COUNT : Types.WORD := 0; 
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STATUS_ERROR : EXCEPTION; -- if data negative 


-- define subprograms and tasks 


procedure Initialize; -- initialization of screen 


task type Update_Type is 
entry Signal; 
pragma PRIORITY(Config.update_priority); 
end Update_Type; 
for Update_Type’STORAGE_SIZE use INTEGER(Config.bytes _per_storage_unit * 
stack_size); 
Update : Update_Type; 


end Status; 
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-°] UNIT: Status Package Body. oe 
--| Effects: Maintains indicators and statistics on graphics display. -- 
--[ Modifies: Flags are cleared in spec. when values ere displayed. oc. 


5: Requires: Initialization must be signaled for first display. 5:5 
--] Raises: No explicitly raised exceptions are propagated. -- 
κι Engineer: M. Sperry. -- 


-- Date : 11-08-88 

τ Purpose : 

-- The purpose of the status package body is the implementation of the status 
σ“- update task. Although operating at a low priority, the update task updates 
+- the various statistics by a rendezvous with the graphics task. 


with Graphics; 

with Interrupt_Control; 

with Shapes; 

with Machine_Dependent; 

with Interrupt_Control; 

with Debug 10; 

with Time Stamp; 

pragma ELABORATE(Graphics, Interrupt_Control, Debug_!0, Time Stamp); 


pacxage body Status is 
use Types; -- for visibility to ‘+; 


procedure Initialize is 
-- A procedure which initializes the scree, for the various statistics 
-- descriptions. It also signals the status update task. 


TITLE_PRIORITY : Graphics.PRIORITY_TYPE := Graphics.LOW; 


‘TITLES : Graphics.MOVE_LIST_TYPE(1..12) :2 
(€(0,0),(0,0), (Shapes. TEXT_MODE,"Airborne "),Graphics.status_color), 
((0,0),(0,1), (Shapes. TEXT_MODE,“ Rockets: "),Graphics.status_color), 
((0,0),(0,3), (Shapes. TEXT_MODE , “Tracked “), Graphics.status_ color), 
(€0,0),(0,4),(Shaces.TEXT_MODE," Targets: “),Graphics.status_color), 
¢€0,0),(0,8), (Shapes. TEXT _MODE,"Totals "),Graphics.status_ color), 
((0,0),(0,10), (Shapes. TEXT _MODE,"Expended “),Graphics.status_color), 
((0,0),(0,11), (Shapes. TEXT_MODE," Rockets: “),Graphics.status_color), 
((0,0),(G,13), (Shapes. TEXT_MODE,"Destroyed “),Graphics.status_color), 
((0,0),(0,14), (Shapes. TEXT_MODE," Targets: "),Graphics.status_color), 
((0,0), (0,18), (Shapes. TEXT_MODE , "Mode: “), Graphics.status_ color), 
((0,0),(0,20), (Shapes. TEXT_MOOE," Menual "),Graphics.status_color), 
((0,0),(0,22), (Shapes. TEXT_MODE,“Automatic "),Graphics.status_color)); 


begin 
Graphics Display. Move(TITLE PRIORITY, TITLES); 
Interrupt_Control Disable; “. go atomic 
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Status.REQ_COUNT :@ Status.REQ COUNT + 1; -- signal ὁ request (print zeroes) 
Interrupt_Controt .Enabie; = 
Status .Update.Signal; 


end Initialize; 


task body Update_Type is 


use Types; 


x_start 

x_end 
y_top_start_A 
y_bottom_start_A 
y_top_start_M 
y_bottom_start_M 
manual_offset 
dox_start 
box_end 

base_x 


airborne_y ᾽ 


tracked_y 


expended_y 
destroyed_y 


y_statistics 


oe se 86 οἡ δὸ δ. 99 δ fe Ὁ "Ὁ. ek te 


constant 
constant 
constant 
constant 
constant 
constant 
constant 
constant 
constant 
constant 
constant 
constant 
constant 
constant 


constant 


τ display statistics values 


-- for visibility to "+" 


5 11; -- colum that status_box starts in x 
85 90; τ end column of status_box 

25 307; τ status_box top AUTOMATIC 

22 322; +> status_box bottom AUTOMATIC 

ss 278; “- status_box top MANUAL 

3:2 293; *- status_box bottom MANUAL 

32 29; °- offset to draw status_box 

32 1; -- range of components that 

33 4; <> make up status_box. 

Types .COORDINATE := 120;-- x end of all statistics 


Types .COORDINATE :# 25; -- y location of stat 
Types.COORDINATE :- 67; -- y location of stat 
Types COORDINATE := 165; -- y location of stat 
Types.COORDINATE := 207; -- y location of stat 


array(STATUS_TYPE’ first .. STATUS_TYPE’ last) of 


Types.COORDINATE :# (airborne_y, tracked_y, expended_y, destroyed_y); 


type STATUS_OLO js array(STATUS_TYPE’first .. STATUS_TYPE’ last, 
1 .. Config.statistics_length) of Graphics.MOVE_RECORD; . 


NEXT_MODE 
DISPLAY_REQUIRED 
NEXT_DATA 
BOX_LIST 
DATA_OLO 
WORK_LIST 
MOVE_PRIORITY 


MODE_TYPE; 


BOOLEAN; 


Types . WORD; 
Graphics .MOVE_LIST_TYPE(Types.WORD_INDEX range box _start..box_end); 
STATUS_OLD; 


Graphics. 


MOVE_LIST_TYPE(1 .. Config.statistics_length); 


Graphics.PRIORITY_TYPE := Graphics.LOW; 


procedure Initialize is 


-- A procedure which intializes the ODATA_OLD data base. This procedure does 

-- NOT cause the digits to be drawn. Then, it initializes the status_box sround 
-- ‘manual’. Again, it does not cause the status_box to be drawn. A wakeup 

“- from the main task will cause it to be drawn. 


begin 


for 1 in STATUS_TYPE’ first .. STATUS_TYPE’ (last loop 
for J in 1 .. Config.statistics_length loop 


DATA_OLD(I,J).XY_OLD 
DATA_OLD(1,J).XY_NEW 
DATA_OLD(1, J) OBJECT 


2s (Types. COORD INATE(base_x), Types. COORDINATE(y_statistics(1))); 
t= (Types. COORDINATE (base_x), Types. COORDINATE(y_ stetistics(!))); 
sm (Shapes .PIXEL_MODE , Shapes .ZERO); 
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DATA_OLD(1,J).COLOR :5 Graphics.status_color; 
end loop; 
end loop; 
+> Now initialize top of status_box 
BOX_LISTC1).XY_OLO := 
(Types. COORDINATE(x_start), Types .COORDIWATE(y top_start_A)); 
BOX_LIST(1).XY_NEW := 
(Types .COORDINATE(x_start), Types. COORDINATE(y top_start_A)); 
BOX_LIST(1).OBJECT :2 (Shapes.P1XEL_MODE , Shapes .HORIZONTAL); 
BOX_LIST(1).COLOR := Graphics.status_box_color; 


-- define bottom of status_box 
BOX_LIST(2).XY_OLO 1:5 
(Types .COORDINATE(x_start), Types.COORDINATE(y bottom _start_A)); 
BOX_LIST(2).x¥_NEW :5 
(Types ..COORDINATE(x_ start), Types.COORDINATE(y_bottom_start_A)); 
BOX_LIST(2). OBJECT :Ξ (Shapes.PIXEL_MODE, Shapes HORIZONTAL); 
BOX_LIST(2).COLOR :2 Graphics.status_box_color; 
-- define left side of status_box 
BOX_LIST(3).XY_OLD :2 
: (Types .COORDINATE(X_start), Types.COORDINATE(y_top_start_A)); 
BOX_LIST(3).XY_NEW :2 
(Types .COORDINATE(x_start), Types.COORDINATE(y_top_start_A)); 
BOX_LIST(3) OBJECT :3 (Shapes.PIXEL_MODE, Shapes. VERTICAL); 
BOX_LISTC3).COLOR 1:5 Graphics.status_box_color; 


-- define right side of status_box 
BOX_LIST(4).XY_OLD :53 
(Types ..COORDINATE(x_end), Types.COORDINATE(y top_start_A)); 
BOX_LISTC4).XY_NEW 32 
(Types .COORDINATE(X_end), Types.COORDINATE(y top_start_A)); 
BOX_LIST(4).ORJECT := (Shapes.PIXEL_MOOE, Shapes. VERTICAL); 
BOX_LIST(4).COLOR :* Graphics.status_box_color; 
exception 
when others => Debug_!0.Put_Line("Exception raised in Status. initialize”); 
end Initialize; 


procedure Update_Box(NEXT_MODE : MODE TYPE) is 


-- A procedure which updates the four objects which represent the status box 
-- surrounding one of the modes. 


OFFSET : Types.WORO; 
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begin 
«-$TP(0078) Status.Update Box start z 
{f WEXT_MODE = AUTOMATIC then τι draw status_box at ‘automatic’ 


BOX_LIST(1).XY_NEW.Y := Types .COORDINATE(y_top_start_A); 
BOX_LIST(2).XY_NEW.Y := Types .COORDINATE(y bottom _start_A); 
BOX_LIST(3).XY_NEW.Y :π Types.COORDINATE(y_ top_start_A); 
BOX_LIST(4).XY_NEW.Y :4 Types. COORDINATE(y_top_start_A); 

else -- draw status_box δὶ ‘menual’ 
BOX_LIST(1).XY_NEW.Y :# Types.COORDINATE(y top _start_M ); 
BOX_LIST(2).XY_NEW.Y := Types.COORDINATE(y_bottom_start_M); 
BOX_LIST(3).XY_NEW.Y := Types.COORDINATE(y top start_M); 
BOX_LIST(4).XY_NEW.Y :* Types.COORDINATE(y_top_start_M); 

end if; 


-- Rendezvous with Graphics to draw new status_box 


--$TP(0079) Status.Update Box rendezvous with Graphics start 
Graphics.Display.Move(MOVE_PRIORITY, BOX_LIST(Types.WORD_INDEX range box_start..box_end)); 
-°$TP (0080) Status .Update_Box tendezvous with Graphics end 


+> Update status_box lists 
for 1 in Types.wORO_IWOEX range box_start .. box_end loop 
BOX_LISTCI).XY_OLD := BOX_LIST(I).XY_NEW; 
end Loop; 
--$TP(0081) Status.Update_Box end 
end Update_Box; 


procedure Display_Digits(NEXT_DATA : im out Types.WORD; 
STAT 9 STATUS_TYPE) is 


-- A procedure which takes the DATA_OLD numbers, divides by 10 to get a single 
-- digit. That digit is used as an index into Shapes.NUMERIC, which holds 
“τ values to draw that number for Graphics. It updates DATA_OLD in the process. 


OIGIT 3 Types.WORD; 
STAT_X_LOC : Types.COORDINATE; 
begin 


+*$7P(0082) Status.Display_Digits start 


--. Erase previous data 

for I in 1 .. Config.statistics_length loop 
DATA_OLD(STAT,1).COLOR := Graphics.background_color; 
WORK_LIST( Types .WORD_INOEX(I)) :5 DATA_OLD(STAT,1); 

end loop; 

--S$TP(0083) Status.Display_Digits rendezvous with Graphics(1) start 

Graphics.Display.Move(MOVE_PRIORITY,WORK_LIST); 

--$TP(0084) Status.Oisplay_ Digits rendezvous with Graphics(1) end 
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-- Move new into old, then display 
STAT _X_LOC := bese_x; 
for I in reverse 1 .. Config.statistics length loop 
DIGIT 2s NEXT_DATA mod 10; -- get rightmost digit 
DATA_OLD(STAT, 1) OBJECT : =(Shapes .PIXEL_MODE , Shapes .NUMERICCINTEGER(DIGIT))); 
DATA_OLD(STAT,1}).COLOR :π Graphics.status_color; 
DATA_OLO(STAT,1).XY_NEW.X := STAT_X_ LOC; 
STAT_X_LOC :- STAT_X_LOC - Shapes.mumber_width; -- moving left 
WORK_LIST(Types.WORD_INDEX(1)) :5 DATA_OLD(STAT,1); 
NEXT_DATA := NEXT_DATA / 10; “- get next digit 
end ‘0p; 
--$TP(0085) Status.Display_Digits rendezvous with Graphics(2) start 
Graphics Display. MOVE(MOVE_PRIORITY ,WORK_LIST); 
--$TP(0086) Status.Display Digits rendezvous with Graphics(2) end 
--$TP(0087) Status.Display Digits end 
exception , 
when others => 
Debug_10.Put_Line("Exception raised in Status.Display_ Digits”); 
end Display_Digits; 


-- body of UPDATE task 
Bugin 
Initialize; 
loop 
--$TP(0114) Status task start 
--$TPCOT1S) Status accept Signal start 
accept Signal; 
-~$TP(0088) Status accept Signal end 
Interrupt_Control .Enable; 
begin -- exception block 
loop 
Interrupt_Control .Disable; 
DISPLAY REQUIRED := ποῖ MODE DISPLAYED; 
NEXT_MODE := MODE; 
MODE DISPLAYED := TRUE; 
Interrupt_Control .Enable; 
if DISPLAY _REQUIRED then στ update new status_box 
Update_Box(NEXT_MODE); 
end if; 
for 1 im STATUS_TYPE’ first .. STATUS_TYPE’ last loop 
Interrupt_Control Disable; 
DISPLAY_REQUIRED := ποῖ STATUS CONTROL(!).DISPLAYED; 
NEXT_DATA :5 STATUS_CONTROL(1) DATA; 
STATUS_CONTROL(I).DISPLAYED := TRUE; 
Interrupt_Controt .Enabte; 
if DISPLAY_REQUIRED then 
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Oisplay_Digits(NEXT_DATA,1); = 
end if; 
end loop; 
Interrupt_Control .Disable; 
REQ_COUNT := REQ_COUNT - 1; 
exit when REQ_COUNT = 0; 
Interrupt_Control .Enable; 
end loop; 
--$TP(0089) Status task end 
exception 
when others => Debug !0.Put_Line("Exception raised in Status task"); 
end; 
end loop; 
end Update_Type; 


end Status; 
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o-| UNIT: Sync Package Spec. -- 
Ὁ Effects: No current use. Will provide greater synchronize in futr.-- 
+>] Modifies: No global data is modified. “- 
τοΆ Requires: No initialization is required. -- 
~-| Raises: No explicitly raised exceptions are propegated. -- 
5. Engineer: Τὶ Griest. τὰ 


“- package to synchronize clocks, will contain a task to call simulator 
-- clock entries 


with Types; 
package Sync is 


type TIME_TYPE’ is new Types.WORD; 
end Syne; 
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--| UNIT: Target Packege Spec. “- 
+-| Effects: Provides structure for BOS Target menagement. “: 
++] Modifies: No global data is modified. ed 
*-] Requires: No initialization is required. o- 
κε, Raises: No explicitly raised exceptions are propagated. τ.» 
5.] Engineer: Τὶ Griest. 7. 


Ce ORe Me See Pete swe sere weset scenes ΧΧΧΎΧΧΧΧΧΧΧΥΎΎΧΧΣῚ 


-* package Target provides target tracking and display management 


with Types; 
with Config; 
packege Target is 


track_stack_size 3 constant := 3928; 
track_data_stack_size : constant :2 1506; 


subtype TARGET_IO_TYPE is Types.WORD_INDEX range 0..Config.max_targets; 


type TARGET_ITEM_TYPE is record +>| provides individual target information 


TARGET_ID ς TARGET_ID_TYPE; 
POSITION s Types.POSITION_TYPE; 
TARGET_CLASS : Types. TARGET_CLASS TYPE; 
end record; 
type TARGET _LIST_TYPE is +-] list of all available targets items 


array(Types.WORD_INDEX range <>) of TARGET_ITEM_TYPE; 


type TARGET_MSG_TYPE is record στ incoming message from Sensor 
NUM_TARGETS 3 Types.WORD_INDEX; 
TARGET LIST + TARGET_LIST_TYPE(Types. TARGET_INOEX_TYPE); 


end record; 


type TARGET_STATUS_TYPE is record 


ACTIVE | : BOOLEAN; 

ENGAGED : BOOLEAN; 

CLASS : Types. TARGET_CLASS_TYPE; 
end record; 


for TARGET_STATUS_TYPE use record 
ACTIVE at 0 range 0..0; 
ENGAGED at 0 range 1..1; 
CLASS at 0 range 2..3; 

end record; 


type TARGET DATA_TYPE is record 
STATUS : TARGET_STATUS TYPE; 
POS!T1ON_NEW : Types.POSITION_TYPE; 
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POSITION_OLD 8 Types.POSITION_TYPE; 
end record; 


type TARGET_DATA_LIST_TYPE is 
array(Types.TARGET_INDEX_TYPE)of TARGET _DATA_TYPE; 


στ The TRACK task is used to control all of the target display information. 
στ It accepts data from the Sensor and maintains it for the Rocket.Control 
-- task. 


task type Track_Type is 
pragma PRIORITY(Config.track_priority); 
end Track_Type; 
for Track_Type’STORAGE_SIZE use INTEGER(Config.bytes_per_storage_unit * 
track_stack_size); 
Track ; : Track_Type; 


στ The Track Data task is used to buffer the most recent target list. 
-- from the Target.Track task and provide it to the Rocket.Control 

-- task. It also buffers new engagements from the Rocket.Control to 

τι notify the Target.Track task that a new target has been engaged. 

-- Nove that only one new target can be engaged every update interval. 
στ If the NEXT_ENGAGE parameter is 0, this is an invalid TARGET_ID, and 
το implies that no new target is engaged. 


task type Track _Data_Type is 
entry Put(DATA : im TARGET_DATA_LIST_TYPE; --| put new list 
NEXT_ENGAGE 2 out TARGET_ID_TYPE; το. get new engagement 
NEXT_DISENGAGE : out TARGET_ID_TYPE); --| and disengagement 


entry Get(DATA : out TARGET_DATA_LIST_TYPE; --| get new list 
WEXT_ENGAGE s im TARGET_ID_TYPE; στ put new engagement 
NEXT_DISENGAGE : in TARGET_ID_TYPE); τοῦ and disengagement 

pragma PRIORITY(Config.track_data_priority); 
end Track_Data_Type; 
for Track Data Type’ STORAGE_SIZE use INTEGER(Config.bytes_per_storage unit * 
track_data_stack_size); 
Track Data : Track_Oata_Type; 


emi Target; -- package specification 
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5.95. «“-“-““τοοτοτοοοονουσουονυσοο που ποοσοοο  στοσοστοοοοσ οὐ σου οοισσοσσυνοσσο 
- 


o-| UNIT: Target Package Body. “- 
*-{ Effects: Provides structure for BOS Target πογιδροπθηῖ. “- 
“:-| Modifies: No global data is modified. -- 
5. Requires: No initialization is required. “- 
5: Raises: No explicitly raised exceptions are propagated. -- 
“.Ἱ] Engineer: T. Griest. . .- 


Pewee mas eweesesocencesees weeweresvencecccocccs ον σ 9 5-...5..55 “.-..-- worcace “. 


with Simulate; pragma ELABORATE (Simulate); 


“τ package Target provides target tracking and display management 


ee 


package body Target is 


σε The TRACK task is used to control all of the target display information, 
‘s+ It gets data from the Sensor and maintains it for the Rocket.Controt 
κ᾿ task. 


task body Track_Type is separate; 


το The Track_Data task is used to buffer the most recent target (ist 

το from the Target.frack task and provide it to the Rocket.Control 

το task. It also buffers new engagements from the Rocket.Control to 

-- notify the Target.Track task that a new target has been engaged. 

-> Note that only ome new target can be engaged every update interval. 
στ If the NEXT_ENGAGE parameter is 0, this is an invalid YARGET_ID, and 
-- implies that no new target is engaged. 


task body Track_Data_ Type is separate; 


lend Target; -- package body 
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΄ 
ΟΥΤΩΣ 
° 


co] UNIT: Targ_Sup Task Body Subunit. oe 
--| Effects: Provides Simulator motion control for all targets. τὰν 
5] Modifies: No global data is modified. 38 
κεὶ Requires: No initialization is required. -- 
““Ἐ.:Αδίϑες: TARGET _CREATE_ERROR if told to create when max exceeded. “- 
5.} Engineer: M. Sperry. -- 


Cee eee ee Cesc e metres eee eeseswassearesseaseseseesvececensecceoccs sececes weoce 


with Calendar; 

with Debug_10; 

with Unchecked_Conversion; 
with Low_Level_10; 

with Time Stamp; 

use Low _Level_[0; 


pragma ELABORATE (Calendar, Debug_!0, Time_Stamp); 
separate (Simulate.Sensor) 
task body Targ_Sup_Type is 


-- A task which sends a list to the caller describing new targets and 

-- targets which have been destroyed. They are described by not being on 
-- the list. Note that nev targets are created first and then those 

-- that need to be destroyed are processed. This task is timed so that 
-- the list is ready only during 100 millisecond intervals. 


use Calendar; --for visibility to "-" 
use Types; --for visibility to "/" etc. 


type MOTION _REC is record 
OFFSET : Types.METERS; 
COUNT : Types.WORD; 


end record; 
start_y 3 Constant Types.METERS :Ξ 3960.0; 
3 start_2 3 constant Types METERS := 0.0; 
. distance _per_report : constant Types.METERS := 2.0; -- meters in Y per report 
safety_factor : constant Types.METERS := 48.0; -- inner border limits 


min_dir_time constant Types.WORD := 20; -- direction travelling time 


TARGET_LIMIT : Types.WORD_INDEX := 5; 
TARGET_COUNT 3 Types.WORD_INDEX : 0; -- local count of targets 
TARGET_COUNTER 3 Types.WORD_INDEX; “- Target index for array 
CLASS 2 Types. TARGET_CLASS_ TYPE; τι type of class for target 
TARGET_IO : Types. TARGET_INDEX_TYPE :- 1; -- target id used 
MOTION : array(Types.TARGET_IMDEX_TYPE’ first... 
Types. TARGET_INOEX_TYPE‘ last) of MOTION_REC; 

TEMP 3 Types.POSITION_TYPE; -- for fixed compiler bug 
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TARGET_CREATE_ERROR : EXCEPTION; - 
START_TIME : Calendar.TIME; 
DELAY_PERIOO 3: DURATION; 


function WORD_TO_METERS is new Unchecked_Conversion(Types.WORD, Types .METERS); 
function BYTE _TO_WORD is new Unchecked_Comversion(Low_Level_!0.8YTE, Types.WORD); 


function RNO return Types.WORD is 


counter_two 2 constant Low_Level_I0.PORT_ADDRESS : 16#42#; 
DATA : Low Level _10.8YTE; 

RANDOM_NUMBER : Types.WORD; 

begin 


Low_Level_10.Receive_Control(counter_two,DATA); 
RANDOM_NUMBER := BYTE_TO_WORD(DATA); 
return RANDOM_NUMBER; 

end RNO; 

pragma INLINECRNO); 


procedure Initialize is 


-- A procedure used to intialize the Simulator’s data base, and start the 
-- channel 2 counter which is used to determine the time it takes for a target 
“- to switch directions as well as which direction to turn. 


timer_entrl : constant Low_Level_10.PORT_ADDRESS := 16#43#; 
counter_two : constant Low_Level_I0.PORT_ADORESS := 16#42#; 

intialize ς constant Low_Level_IO.BYTE :5 16#82#; -- mode 2, channel 2 
start_count : constant Low_Level_IO.BYTE :5 16M#FF#; 


begin 
Low_Level_10.Send_Contro((timer_cntrt, intial ize); 
Low_Level_!0.Send_Control(counter_two, start_count); 
Low_Level_10.Send_Control (counter_two,start_count); 
for I in Types. TARGET_INDEX_TYPE’ first. .Types.TARGET_INDEX_TYPE’ last loop 
Simulate. TARGETS(!).ACTIVE :5 FALSE; 
WOTIONCI).OFFSET :π WORD_TO_METERSC(RND / 16 - 8); 
MOTIONC1).COUNT :5 RNO + min_dir_time; 
end loop; 
CLASS :;5 Types. TARGET _CLASS_ TYPE’ FIRST; 
end Initialize; 


procedure Create New Target is 
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-+ A procedure used to create a new target. The first usable ID is taken 
τ to be the new targets ID. Also the target class is changed for every create. 


FOUND : BOOLEAN :# FALSE; 

1D : Types. TARGET_INDEX_TYPE; 
OLO_ID : Types. TARGET_INDEX_TYPE; 
begin 


--$TP(0090) Targ Sup.Create start 
1D := TARGET_IO; 
OLD_ID := TARGET_ID; 
while not FOUND loop 
if not Simulate. TARGETS(I0). ACTIVE then 
Simulate. TARGETS(1D) ACTIVE := TRUE; 
if CLASS = Types. TARGET_CLASS _TYPE’LAST then 
CLASS := Types. TARGET_CLASS TYPE’FIRST; 
else 
CLASS := Types. TARGET _CLASS_TYPE’SUCC(CLASS); 
end if; ἢ 
Simulate. TARGETS( ID). TARGET_CLASS := CLASS; 
Simulate. TARGETS(ID).POSITION.X := WORD_TO_METERS(RND * 15 + 10) * 8; 
Simulate. TARGETS(1D).POSITION.Y := start_y; 
Simulate. TARGETS(ID).POSITION.Z :5 start_z; 
TARGET_COUNT :2 TARGET_COUNT τ; 
TARGET_ID :2 ID; στ keep ro(lover count of TARGET_[0’s 
FOUND := TRUE; 
exit; 
else 
10 :π ID + 1; 
if 10 > Config.max_targets then 
1D :2 1; 
if OLD_ID = ID then 
raise TARGET CREATE _ERROR; 


end if; το Mo more room check 
end if; -- wrap ID check 
end if; +> ACTIVE check 
end loop; 
--$TP(0091) Targ_Sup.Create end 
except’ on 


when others 2> 
Debug_[0.Put_Line("Exception raised in Targ_Sup.Create New_Target."); 
end Create _New_ Target; 


στ Targ_Sup task body 

begin 
Initialize; 
“τ First take the time. 
START_TIME := Calendar .Clock; 
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loop 
+-$TP(0092) Targ Sup task start - 
START_TIME := START_TIME + Config. interval; 
-- Then check number of Targets; if less than maximum, then add a new 
“- Target to the list. 
if TARGET COUNT < TARGET_LIMIT then 
Create _New_Target; 
end if; 
-+ Then move each target. 
for ID in Types. TARGET_INOEX_TYPE!’ first. .Types.TARGET_INDEX_TYPE’ last loop 
if Simulate. TARGETS(1D).ACTIVE then 
Simulate. TARGETS(10).POSITION.Y := Simulate. TARGETS(ID).POSITION.Y - 
distance_per_report; 
Simulate. TARGETS(ID).POSITION.X := Simulate. TARGETS(1D).POSITION.X + 
. MOTIONCID) OFFSET; 
-* Check for hitting against boundaries. 
if Simulate. TARGETS(I0).POSITION.X > Config.meters_in_battle_area then 
Simulate. TARGETSC(ID).POSITION.X := Config.meters_in_battle_erea - 
safety_factor; 
MOTIONCID) OFFSET := -(MOTIONCIO) .OFFSET);--move in opposite direction 
MOTIONCID).COUNT := RNO + min_dir_time; 
elsif Simulate. TARGETS(ID).POSITION.X < safety_factor then 
Simulate. TARGETS(ID).POSITION.X := safety_factor; 
MOTIONCID) OFFSET := -(MOTION(ID).OFFSET);--move in opposite direction 
MOTIONCID).COUNT := RND + min_dir_time; ᾿ 
end if; 
MOTION(ID).COUNT := MOTION(ID).COUNT - 1; 
if MOTIONCIO).COUNT = 0 then -- time expired, possibly change direction 
MOTIONCID).COUNT :5 RND + min_dir_time; 
MOTIONCIO).OFFSET := WORD_TO_METERSCRNO / 16 - 8); 


end if; -- timeout on direction check 
end if; “τ ACTIVE check 
end loop; 


στ Then see if any targets made it to the enemy line. 
-- These targets are no longer the concern of the BOS. They 
-- are deleted from the list. 
for I in Types.TARGET_INOEX_TYPE loop 
if Simulate. TARGETS(I).ACTIVE then 
it Simulate. TARGETS(1).POSITION.Y < 40.0 then 
TARGET COUNT := TARGET COUNT - 1; 
Simulate. TARGETS(1).ACTIVE := FALSE; 
end if; 
end if; 
end Loop; 
-+ Finally move the list into the target list kept by the target spec. 
--$TP(0093) Targ Sup accept Next _Target_Msg start 
accept Next_Target_Msg(DATA : out Target.TARGET_MSG_TYPE) do 
TARGET COUNTER :5 0; 
for 1 in Types. TARGET_INOEX_TYPE loop 
if Simulate. TARGETS(1).ACTIVE then 
TARGET COUNTER := TARGET_COUNTER ¢ 1; 
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TEMP :- Simulate. TARGETS(1).POSITION; -- “fixed compiler code bug 
DATA.TARGET_LISTCTARGET COUNTER) .POSITION := TEMP; 
DATA. TARGET_LISTCTARGET_COUNTER).TARGET_CLASS := 
Simulate. TARGETS(1).TARGET_CLASS; 
DATA. TARGET_LIST(TARGET_COUNTER).TARGET_ID := 1; 
end if; 
end loop; 
TARGET_COUNT := TARGET_COUNTER; 
DATA.NUM_TARGETS := TARGET_COUNTER; 
end Next_Target_Msg; 
--$TP(0094) Targ Sup accept Next_Target_Msg end 
DELAY_PERICO := START_TIME - Calendar .Clock; 
if DELAY_PERIOO < 0.0 then 
START_TIME := Calendar .Clock; 
end if; 
+-$TP(0095) Targ_Sup end 
delay OELAY_PERIOO; 
end loop; 
στ eccept Clock(Time : ἴω Syne.TIME_TYPE); --TBO 
end Targ Sup_Type; 
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o+| UNIT: Track Task Body Subunit. = 55 
κι Effects: Provides all target tracking and display for 80S. -- 
5.1] Modifies: No global data is modified. “- 
τοῦ! Requires: No initialization is required. “- 
--{ Raises: Wo explicitly raised exceptions are propagated. -- 
--| Engineer: Τ'. Griest. ; δ 


OPO we OOOO OOF eee Seas erase eeetwecesreceeneesareeserereneceteseeuresseseee 


with Graphics; 

with Shapes; 

with Interrupt_Control; 

with Grid_to Pixel; 

with Simulate; 

with Debug_I0; 

with Status; 

with Time_Stamp; 

pragma ELABORATE(Graphics,Shapes, Interrupt_Control ,Grid_to_Pixel, 
΄ Simulate, Debug_I0, Status, Time_Stamp); 


separate (Target) 
στ The TRACK task is used to control all of the target display information. 
στ It accepts data from the Sensor and maintains it for the Rocket.Control 


“νι task. 


task body Track_Type is 


use Types; 

package Sensor renames Simulate.Sensor; -- make simulation transparent 

use Types; -- for operators only 

TARGET_MSG s TARGET_MSG_ TYPE; 

MOVE_ TARGETS : Graphics. MOVE_LIST_TYPE(Types.TARGET_INDEX_TYPE); 

MOVE _ INDEX s Types. WORD_INDEX; 

OESTROYED : Types .WORD; 

CREATED : Types.WORD; 

PIXEL POINT : Shapes .PIXEL; 

TARGETS : TARGET _DATA_LIST_TYPE; 

MSG_ INDEX : Types .WORD_INDEX; 

NEXT ENGAGED : Types .WORD_INOEX; -- 0 ff no new engagement 

NEXT _DISENGAGED : Target. TARGET_ID_TYPE;-- keep track of disengagements 

COLOR : Graphics.COLOR_TYPE; 

ENGAGE _FLAG : BOOLEAN; 

CLASS : Types. TARGET CLASS TYPE; 

POSIT 10M : Types.POSITION_TYPE; -- temp for making changes 
begin 


στ IMITIALTZATION 


for 1 {nm TARGETS’ range loop 
TARGETS(1). STATUS := (FALSE, FALSE ,UNKNOWN); -- init to default 
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end loop; = 


loop 


**STP(0096) Track tesk start 

=-$TP(0097) Treck rendezvous with Targ_Sup start 
Sensor .Targ_Sup.Next_Target_Msg( TARGET_MSG); 
+-STP(0098) Track rendezvous with Targ Sup end 


.ς. cc m@ins- 


Zero out counters 


CREATED := 0; 
DESTROYED := 0; 


Maintain history information. 


Go through each target to examine its new status 


MSG_INDEX :5 1; 
MOVE_INDEX := 0; 
for TARGET _ID in TARGETS'RANGE loop 


if TARGETS(TARGET_10).STATUS.ACTIVE then 


if MSG_INDEX > TARGET_MSG.NUM_TARGETS or else 
TARGET_MSG.TARGET_LIST(MSG_INOEX).TARGET_I0 
7π TARGET_ID then -- target destroyed 


Taryet has been destroyed, keep local accumulation of destroyed 
targets, and add to list for Display task to erase target. 


mark as inactive 


OESTROYED := DESTROYED + 1; 
(ACTIVE => FALSE, ENGAGED => FALSE, CLASS => UNKNOWN) 
TARGETSCTARGET_10).STATUS :Ξ (FALSE, FALSE, Types.UNKNOWN); 
MOVE_INDEX :Ξ MOVE_INDEX + 1; 
PIXEL_POINT :- Grid_To_Pixel (TARGETS(TARGET_ID).POSITION_NEW); 
COLOR := Graphics.background_color; 
MOVE_TARGETS(MOVE_INDEX) :5 (PIXEL_POINT, 
PIXEL_POINT, 
(Shapes .P1XEL_MOODE , Shapes. TARGET), 
COLOR); 
else “- move the target 


Found a current existing target in the latest sensor report, 
update target information and add it to move list. 


POSITION := TARGET _MSG. TARGET _LIST(MSG_ INDEX) .POSITION; 

WOVE _INDEX :* MOVE_INOEX + 1; 

CLASS := TARGETS(TARGET_10).STATUS.CLASS; 

ENGAGE FLAG :5 TARGETS(TARGET_10).STATUS.ENGAGED; 

COLOR :- Graphics.target_color(CLASS, ENGAGE_FLAG); 

MOVE_TARGETS(MOVE_INDEX) := 
(XY_OLD => Grid_to_Pixel (TARGETS(TARGET_1D).POSITION_NEW), 
XY_NEW => Grid_to_ Pixel (POSITION), 
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OBJECT => (Shapes.PIXEL_MOOE, Shapes. TARGET), 
COLOR => COLOR " 
» 
TARGETS(TARGET_10).POSITION_OLD := ΤΑΚΟΕΤΘ(ΤΑΚΟΕῚ 10) ΡΟΘΙΤΊΟΝ ΝΕΜ; 
TARGETSCTARGET_ID) .POSITION_NEW : POSITION; 
MSG_INOEX := MSG_INDEX + 1; 
end if; “- new/old target check 
else “- this target wasn’t previously active 
if MSG_INDEX <= TARGET _MSG.NUM_TARGETS and then 
TARGET_MSG.TARGET_LIST(MSG_INDEX).TARGET_ID 
® TARGET_ID then -- new target 


-- New Target has been created, set status and put it on display 
CREATED := CREATED + 1; 


“- mark as active 
TARGETSCTARGET_ID).STATUS := 


(TRUE, 7° ACTIVE 
, FALSE, “- Engaged 
TARGET_MSG.TARGET_LIST(MSG_INDEX).TARGET_CLASS); -- class 
TARGETSCTARGET_{D).POSITION_OLD := -- set both old and new 


TARGET _MSG. TARGET _LIST(MSG_INDEX) .POSI TION; 
TARGETSCTARGET_10).POSITION_NEW <= 
TARGET_MSG.TARGET_LIST(MSG_INDEX) POSITION; 
MOVE_INDEX := MOVE_INDEX + 1; 
CLASS := TARGETS(TARGET_1D).STATUS.CLASS; 
ENGAGE_FLAG :- TARGETS(TARGET_ID).STATUS.ENGAGED; 
COLOR := Graphics.target_color(CLASS, ENGAGE_FLAG); 
MOVE_TARGETS(MOVE_INDEX) :5 
(XY_OLD #> Grid_to_ Pixel (TARGETS(TARGET_10).POSITION_OLD), 
XY_NEW => Grid_to_Pixel (TARGETS(TARGET_ID).POSITION_NEW), 
OBJECT => (Shapes.PIXEL_MODE, Shapes. TARGET), 
COLOR => COLOR 
3 
MSG_INDEX := MSG_INDEX + 1; 


end if; “ιν end of new target check 
end if; ὲ “. active check 
end loop; 


-- Now update status if any created or destroyed 


if CREATED /= DESTROYED or OESTROYED > 0 then 
Interrupt_Controt Disable; 
Status.STATUS_CONTROL (Status. TRACKED) DATA := 
Status. STATUS_CONTROL (Status. TRACKED) .OATA + (CREATED - DESTROYED); 
Status. STATUS CONTROL (Status. TRACKED) DISPLAYED :© FALSE; 
Status. STATUS_CONTROL (Status .DESTROYED) DATA := 
Status. STATUS CONTROL (Status .DESTROYED).DATA * DESTROYED; 
Status. STATUS_CONTROL (Status .DESTROYED).DISPLAYED := FALSE; 
Stetus.REQ_ COUNT := Stetus.REG COUNT + 1; 
if Status.REQ_COUNT = 1 then 
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--$TP(0099) Track rendezvous with Status start 
Status .Update.Signal; 

°-$TP(0100) Track rendezvous with Status end 

end if; 

Interrupt_Control .Enable; 
end if; 
-~$TP(0101) Track rendezvous with Track _Data start 
Target.Track_Dats.Put( TARGETS, NEXT_ENGAGED , NEXT_DISENGAGED); 

-* send copy to Rocket.Control 

-~$TP(0102) Track rendezvous with Track Data end 
if NEXT_ENGAGED > Ὁ then 

TARGETS(NEXT_ENGAGED ).STATUS.ENGAGED := TRUE; -- set engaged 
end if; 
if NEXT_DISENGAGED > 0 then 

TARGETS(NEXT_OISENGAGED) .STATUS.ENGAGED := FALSE; 
end if; 
--$TP(0103) Track rendezvous with Graphics start 
Graphics .Display.Move(Graphics.LOW, MOVE_TARGETS(1..MOVE_INDEX)); 
+-$TP(01046) ‘Track rendezvous with Graphics end 
+-$TP(0105) Track task end 

end loop; 
exception 
when others => 
Neoug_10.Put_Linec"TRACK termination due to exception."); 
ered Track_Type; 
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“-“-““-..... Mewes meaveseves tase enesresesseesacesoeeseeceaceuscoseoseusoesce 


o-| UNIT: Track Data Tesk Subunit. > «-- 
σε. Effects: Provides buffering of target tracking data between the hg 
51] Track task διά the Control task for rocket engagement. == 
+-| Modifies: No global data is modified. ΞΡ 
+*| Requires: No initialization is required. 55 
++| Raises: No explicitly raised exceptions are propagated. -- 
51: Engineer: T. Griest. -- 


ΕΣ ΧΎΥΣ “..... “-..--..--- “.-.....» “..---.---. ““-“ς.-.“ς.“.“-“.-.5.5“5.5.505 


with Time_Stamp; 
with Interrupt_Control; 
pragma ELABORATE(Time_Stamp, Interrupt_Control ); 


separate (Target) 


στ The Track_Data task is used to buffer the most recent target list 

-- from the Target.Track task and provide it to the Rocket.Control 

το task. It also buffers new engagements from the Rocket .Control to 

-- notify the Target.Track task that a new target has been engaged. 

-- Note that only one new target can be engaged every update interval. 
στ the NEXT_ENGAGE parameter is 0, this is an invalid TARGET_ID, and 
τ implies that no new target is engaged. 


task body Track _Data_Type is 
use Types; 


BUFFERED_DATA : Target. TARGET_DATA_LIST_TYPE; 
BUF FERED _ENGAGE : Target. TARGET _ID_TYPE; 
BUFFERED_OISENGAGE : Target.TARGET_ID_TYPE; 
DATA_COUNT : Types.WORD := 0; 
begin 
στ Initialize tocal copy of data 
e+ {nitielize all target status to: 
5:5 (ACTIVE 2> FALSE, ENGAGED => FALSE, CLASS => UNKNOWN) 


BUFFERED_ENGAGE := 0; -- default is no new engagement 


for 1 in BUFFERED DATA’ range loop 

BUFFERED_OATACI).STATUS := (FALSE, FALSE, Types.UNKNOWN); 
end oop; 
loop 

select 

accept Put(DATA : im TARGET _DATA_LIST_ TYPE; 

NEXT_ENGAGE : out TARGET_ID_TYPE; 
WEXT_DISENGAGE : out TARGET_ID_TYPE) do 
--$7P(0106) Trackdat sccept Put start 
Interrupt_Control .Disable; 
BUFFERED_DATA := DATA; 
tnterrupt_Controt .Enable; 
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NEXT_ENGAGE :5 BUF FERED_ENGAGE ; Φ 
WEXT_DISENGAGE :5 BUF FERED_DISENGAGE ; 
DATA_COUNT := 1; 
--$TP(0107) Trackdat accept Put end 
end Put; 
or 
when DATA_COUNT > 0 => 
ee accept Get(OATA : out TARGET_DATA_LIST_TYPE; 
NEXT_ENGAGE : im TARGET_ID_TYPE; 
NEXT_DISENGAGE : in TARGET_ID_TYPE) do 
. --$TP(0108) Trackdat accept Get start 
Interrupt_Concrol Disable; 
DATA :2 BUFFERED_DATA; 
Interrupt_Control .Enable; 
BUFFERED_ENGAGE := NEXT_ENGAGE; 
BUFFERED_DISENGAGE :5 WEXT_DISENGAGE ; 
DATA_COUNT := 0; 
--$TP(0109) Trackdat accept Get end 
end Get; 
end select; 
end loop; 
end Track_Data_Type; 


-173- 


Demonstration Project Final Report 


*-| UNIT: Traject Function Spec. -- 
“τὶ Effects: Computes rocket motion based on previous motion and “- 
51 aimpoints received in guidance messages. -- 
στ Modifies: No global data is modified. -- 
στὶ Requires: No initialization is required. -- 
τι Raises: No explicitly raised exceptions are propagated. -- 
5: Engineer: T. Griest. os 


waeweccoen Sew ewer eretoverccecowosnceseerecassiocsresrewesecetvacueeserssocese 


s+ Traject: Is the trajectory planner for taking an Azimuth, Elevation 


-- X,Y,2 position and constant velocity and producing a new 
“- position 
with Types; 


function Traject(POSC : Types.POSITION_TYPE; AIMPOINT : Types.AIMPOINT_TYPE) 
return Types.POSITION_TYPE; 
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weceweceasece Pee ee ee eee ee eee 
΄ 


o>] UNIT: Traject Function Body. “- 
5: Effects: Computes rocket motion based on previous motion and =" 
“1 aimpoints received in guidance messages. “- 
5: Madifies: No global data is modified. “5 
5 Requires: No initialization is required. os 
51 Raises: Wo explicitly raised exceptions are propagated. oo 
--| Engineer: T. Griest. -- 


τ Trajects Is the trajectory planner for taking δὴ Azimuth, Elevation 
-- X,Y,2 position and constant velocity and producing a new 
“. position 

with Math; 

with Time Stamp; 

pragma ELABORATE{Math, Time_Stamp); 


function Traject(POSO : Types.POSITION TYPE; AIMPOINT : Types.AIMPOINT_TYPE) 
return Types.POSITION_TYPE is 


use Types; -- for operators 
velocity : constant :π 20; ++ meters per interval 
SCALE : Types.LONG_FIXED; 

ΧΟ, YO, 20 : Types. LONG_FIXED; 

ΧΟ 50 : Types. LONG_FIXED; -- ΧΟ ** 2 

ELEVATION : Types.8AM; 

AZIMUTH : Types.BAM; 

DIRECTION X : INTEGER; 

DIRECTION Y : INTEGER; 

DIRECTION_Z : INTEGER; 


NEW_POS : Types.POSITION TYPE; 
begin 
--$1P(0110) Traject start 
if AIMPOINT AZIMUTH » 0 then 
DIRECTION_Y := 1; 
-- ΑΖΙΜΌΤΗ :- AIMPOINT.AZIMUTH; 
else 
OIRECTION_Y := -1; 
o- AZIMUTH := -AIMPOINT AZIMUTH; 
end if; 


if abs AIMPOINT AZIMUTH <= 16384 then 
DIRECTION Χ :- 1; 
else 
DIRECTION_X := -1; 
=e AZIMUTH :π5 (32767 - AZIMUTH) « 1; 
end if; 
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++ {f AIMPOINT ELEVATION >= Ὁ then - 
"ς OIRECTION_2 := 1; 

“- ELEVATION <= AIMPOINT .ELEVATION; 

s- else 

-- DIRECTION 2 :Ξ -1; 

7: ELEVATION :# -AIMPOINT ELEVATION; 

-- end if; 


YO := 1.0; 
ΧΟ :- Math. TanCAIMPOINT AZIMUTH); 
if x0 = 0.0 then 

ΧΟ := Types.sqrt_large_number; 
else 

ΧΟ :3 Types.LONG_FIXED( Types. LONG_FIXED(1.0)/Xx0); 
end if; 
ΧΟ 56 := Types.LONG_FIXED(XO * ΧΟ); 
20 :- Types. LONG_FIXED(Math. Tan(AIMPOINT .ELEVATION) * 

΄ Math.Sqrt(X0_SQ + Types.LONG_FIXED(1.0)); 


if 20 > Types.sqrt_large_number then 
20 :2 Types.sqrt_targe_number; 
end if; 
SCALE :Ξ Math.Sqrt(YO + X0_Sq + Types.LONG_FIXED(Z0*Z0)); 
NEW_POS.X s= Types.METERS(velocity * DIRECTION_X © abs XO / SCALE) + POSO.X; 
NEW_POS.Y :2 Types.METERS(Types.LONG_FIXED(velocity) / 
. ‘ SCALE)*DIRECTION_Y + POSO.Y; 
NEW_POS.2 :2 Types.METERS(velocity * 20 / SCALE) + POSO.2; 
--$1P(0111) Traject end 
return NEW_POS; 
end Traject; 
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wocee ewe wee e rvs veer ee secees west eeses secre cacsesn ees ewes eservecccscesteocceccs 


΄ 


ΖΓ UNIT: Types Package Spec. <s 
+-| Effects: Provides general purpose data types. -- 
>] Modifies: No global data is modified. -- 
5 Requires: No initialization is required. << 
σὲ. Raises: No explicitly raised exceptions are propagated. ad 
κι Engineer: T. Griest. “- 


wee στο τσ ο σπου σσοποοσυσοσοσ.5. ΧΩ 


»- Date : 10-10-88 

-- Purpose : 

-- The purpose of Types is to provide common project specific data types that 
το are not related to any particular application area. 

with Config; 


package Types is 


type WORD is range -32768 .. 32767; 
for WORD’size use 16; 


type WORD_INDEX is range 0 .. 32767; 
for WORD_INDEX’size use 16; 


subtype WORD_COUNT is WORD range 0 .. 32767; 


subtype ROCKET_INDEX_TYPE is WORD_INDEX range 1..Config.max_rockets; 
subtype TARGET_INDEX_TYPE is WORD_INDEX range 1..Config.max_targets; 


subtype COORDINATE is Types.WORD; 
subtype REL_COOROINATE is Types.WORO; 
_ type METERS is delta 0.125 range -Config.meters_in_battle area .. 


Config.meters_in_battle_area; 


type LONG _FIXED is delta 0.015625 range -33_554 432.0. .33_554_ 431.0; 
for ONG FIXED’size use 32; 


sqrt_large_mumber : constant := 2508.0; -- approx sqrt(LONG_FIXED’ last)/4 


type POSITION_TYPE is record στ for absolute position 
x 3 METERS; στ] assume battlefield oriented ENU 
Y 3: METERS; 
2 ς METERS; 

end record; 


type POSITION_PAIR_TYPE is record --| X,Y,2Z in meters 
TARGET_OLD : Types.POSITION_TYPE; 
TARGET_NEW : Types.POSITION_TYPE; 
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ROCKET_OLD : Types.POSITION_TYPE; 
ROCKET_NEW : Types.POSITION_TYPE; 7 
end record; 
type BAM is range -32768 .. 32767; το. binary engle measurement 32768/180 


--}] East North Up origins (0) 


type AIMPOINT_TYPE is record 
AZIMUTH 3: BAM; 
ELEVATION : BAM; 

end record; 


subtype DISTANCE is METERS range 0.0 .. Config.meters_in_battle_area; 


-- ΤΒΟ - Main Battle Tank 

τι SA9 - GASKIN surface to air missle launcher 

-- BMP2 - Infantry Combat Vehicle 

type TARGET CLASS TYPE is (UNKNOWN, T80, SA9, BMP2); 


end Types; 
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20 Appendix I - Distributed Runtime Source Code 


The source code for the distributed runtime uses an 8086 family 
assembly language code. It is divided into modules which implement 
the major functional areas. These include: program linkage, runtime 

routines, network setup, network I/O, and vendor runtime 
interface. 
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oXLIST 
PR ECROSESES ER OR ESTE IEEE OPER SASSI ESEREERESEEI ITIL 
FILE: OA_DEF.ASM 


Distributed Ada - Definitions 


Definitions for system values 


This Distributed Ada Runtime inherits the LabTek copyright. 
The following copyright must be included in all software 
utilizing this Ada Runtime. 


Copyright 1989 by LabTek Corporation, Woodbridge, CT, USA 


Permission to use, copy, modify, and distribute this 
software and its documentation for any purpose and without 
fee is hereby granted, provided that the above copyright 
notice appear in all copies and that both that copyright 
notice and this permission notice appear in supporting 
documentation, and that the name of LabTek not be used in 
advertising or publicity pertaining to distribution of the 
software without specific, written prior permission. 
LabTek makes no representations about the suitability of 
this software for any purpose. It is provided “as is" 
without express or implied warranty. 


Mo Ne τὸ τὸ Be τὸ te οὐ τὸ Se τὸ te κι “ὁ “΄ τὸ Be we Oe προ Be te Se we es 8 Be Me πο 


Re me te τὸ Be τὸ τὸ τὸ τὸ τὸ Me Be Be πὸ Be πὸ Me τὸ πο Me Bn Me πὸ τὸ Me Fe Ge πὸ “6 


Σ 211 Disclaimer Freee aaa Tae aa aE 
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, e 
; This software and its documentation are provided “AS [S” and : 
; without any expressed or implied warranties whatsoever. ὃ 
; Wo warranties as to performance, merchantability, or fitness Ἢ 
; for es particular purpose exist. ; 
‘ ; 
; in no event shall any person or organization of people be H 
; held responsible for any direct, indirect, consequential : 
; or tinconsequential damages or lost profits. 2 
; : 
Σ᾽ 111} 11 11}}111111 ENO-PROLOGUE fierce ieee eee eae aaa 1121] 


NETWORK MESSAGE CONTROL FIELD VALUES 


destination_addr equ 0 ; Ethernet eddress of receiver 
source_addr equ 6 3 Ethernet address of sender 

RCP equ 12 ; Receive Control Pointer Offset 
priority equ 14 3 Ada priority (not used at present) 
sequence equ 16 3; Pecket Sequence Counter 
data_length equ 18 3 length of data field 
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Offsets from Receive Pointer 
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; Data fields) 


(AT BUFFER*RCP) to various fietds 


OEF_emd_offset equ 0 3 command field 
DEF_pid_ offset equ 2 ? processor [ID 
OEF_tid_offset equ 4 3 task 1D 
DEF_eid_offset equ 6 7 entry Id 
DEF_reply_offset equ 8 3 Reply message 
; Offset from list pointer to next node pointers 
DEF_Next_Ptr equ 2 3 offset to next pointer in buffer 
; ΤῸΒ Offsets 
DEF_TCB_EIO equ 6 7 Offset to Entries in TCB 
OEF_TCB_ENTRY_SIZE equ 4 3 four bytes per Entry 
DEF_TCB_REPLY equ 14 3 offset to rendezvous reply pointer 
reer err ee eee eee eeea eer ee eee ee ey 
; PROCESSOR / TASK / ENTRY IDs ; 
; Notes PIDs increment by 6, ; 
3 TIO0s and ElO0s by 2. ; 
3; TASK [Ds ere unique. : 
PEE eee eee eTe See eT e Vere eee eee ee 
vEF_alpha_oddress struc 
; db 2, 96,140, 68, 82, 9 
db 2, 96,140, 71, 99, 85 
DEF_alpha_address ends 
OEF_bravo_address struc 
: ab 2, 96,140, 58H, 35H, 58H 
db 2, 96,1460, 48H, STH, 60H 
OEF_bravo_address ends 
OFF _pid_alpha equ 0 3 Primary Processor 
DEF_pid_bravo equ 6 3 Secoraary Processor 
ΠΧ ΧΧΥΣΥΥΥΣΥΣΥΣΧΧΧΧΥΧΧΧΥΧΥΣΙΧΣΥΧΥΣΧΧΣ ΣΧ ΧΩΧΖΖΙΙΙ 
Σ COMMANDS received via messages 
PEPE PERS ORERESOLERERESELESESESESESEREEEETESESE SES ORAE EERSTE ERSTE ET) 
DEF_elab_begin equ 0 
DEF_elab_end equ 2 
DEF _request_entry equ 4 
OEF_accept_complete equ 6 
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Standard Call Frame: 


Be Be te te “Ὁ 


OEF_task_id equ 6 3; BP + 6 

OEF_TCP equ 8 ; BP + 8 Transmit control pointer 
OEF_Entry equ 8 ; ΒΡ + 8 (also used for entry ID) 
DEF _parameters equ 10 3; BP + 10 

DEF_param_count equ 0 ; feltative to parameters (In/Out) 

DEF _param_offset equ 0 ; followed by segment 

DEF_param_segment equ 2 

DEF_param_length equ 4 ; relative to offset 
DEF_param_descriptor equ 6 3 # of bytes per parameter 
DEF_local_task_id equ 6 3 buffer offset for task_id 
DEF_local_entry_id equ 6 3 offset from BP in local end rendezvous 


δια πα RAHA AAH 


Low address * TASK 1D *  BP+6 
REWRARRAEGHERAETEEAVNAERERE 
. CONTROL PTR bad +8 


RARAARAARERERATAEALELRAENR 


* IN Parameter Count * etc. 
Φουα θα 


ΠΝ PARM1 OFFSET = 


RRARERAEAARARARERA A AAAARER 


* Ν PARM1 SEGMENT be 


RAAARERAAAARARAAAAAETHAEEN 


* IN PARMT LENGTH . 
euersarternenrenteNreesTe 


Se Be Me πὸ Be Me Me τὸ we Be ee πὸ τὸ τὸ BH Be το το “Ὁ 


RERAERSRERRARALRAERATEBAREE 


* IM PARMn OFFSET * 
Seveneenrererrerereereene 


* [WN PARMn SEGMENT * 


RERARRARARAHARAAAARARRAEER 


“ΘΝ PARMn LENGTH ἐς 


ἩΩΘΟ Θ ΦαΘ ΘΟΘ 66999 


Note: Out parameters are accessible via the buffer decriptor 
pointed to by (BX). 


@e te Se Me Me πὸ te Me τὸ fe 
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REMOTE ENO RENDEZVOUS 


oe δὼ “ὦ fy em νὼ Be te Fe Se Fe Se ce Ce Fe Fe δ... Om Sa FO te FR SE δὼ Om FE CH Cm 


BP+6 
+8 
etc. 


eo 2 & a Ee 3+ Ἐν ὦ 
rae ae ee 
ξωξιεξιξεςεἢος-ἐ: ee oe ee 
ἐξ ἐξ εξ εξ εἰ ἐεξξε ει 
fel gi S72 3t beieiai 
- ν.-- -& “-- κα ς 
ἘΠΕ EHH 
ξ ξεξεξςξ fr §s? 
ΠΗ | SSPE] 


Note: Out parameters are accessible via the buffer decriptor 


pointed to by (BX). 


Low address * 


SELECT 


ee κ᾿ δ. κα a a, ee ee, ee Ty 


BP+6 
+8 
etc. 


* 
- 


TASK 10 


ENTRY 1 
ENTRY 2 


RERARAAAAHAAAAeAAeTARAKEs 


RARRTARRARAAAEERAREARERARR 


Low address * 


RAERHARAASAAOTLARNAARENED 


* NUMBER OF ENTRIES 


REPRHORAAAEAATLAASAA AAI 
RARARAAAARARARARAARERARARRR 

. 

eee 

eee 
RERASAAREEAAAARAAAAEAARAEEOR 
teeeeanreartatverterenten 


* ENTRY N 


, 
. 
, 
, 


τὸ τα ee ον ὁπ δὼ τὸ νὦ ο«( ὃς 
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Note: On return, AX contains which entry wes selected, 8X points 


to buffer descriptor or LOCAL DATA address if descriptor next 


pointer is non-null. 


ce oe 


om ce 


. 
[2 
. 
᾿΄ 
. 
, 
. 
΄ 


each block is pointed to by a unique ID, which is the 


Task Control Block Layout 


ee 


offset (address) within the DA code segment of the TCB 


for that TASK. 


Ce ee aes 


Syne_Semaphore: The syne semaphore is used to suspend (or resume) 


ee te te te 


ce “ὦ ce 


execution of the associated task for rendezvous. 


Entry_Table: The Entry table provides a record for each of the 


o 
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LIST 
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Distributed Ada - Hardware Definition Include File 


ΣΣ 11 1 11211) Distribution and Copyright ΣΣΣΣΣΣΣΣΣΣΣΣΣΣ 122 
: LabTek Distributed Ada v1.0 

This Distributed Ada Runtime inherits the LabTek copyright. 

The following copyright must be included in all software 

utilizing this Ada Runtime. 


Copyright 1989 by LabTek Corporation, Woodbridge, CT, USA 


Permission to use, copy, modify, and distribute this 
software and its documentation for any purpose and without 
fee is hereby granted, provided that the above copyright 
notice appear in ail copies and that both that copyright 
notice and this permission notice appear in supporting 
documentation, and that the name of LabTek not be used in 
advertising or publicity pertaining to distribution of the 
software without specific, written prior permission. 
LabTek makes no representations about the suitability of 
this software for any purpose. It is provided “as is" 
without express or implied warranty. 


Be fe Be we τὸ “τὸ τὸ τὸ te τὸ τὸ Me te δ’ ee “ο το 


Se Me οὖ τὸ οὐ πο τὸ te 


or eae eaerreoesecece ὴ ; φΦονοοοοι»φοὐυφοοφουφοφοοοθσοφοο Φι.46ὁ6 
ΥΥΥΥΥΥΥΥΥΣΥΥΣΧΣ.Ζ) Disclaimer ΣΧ ΧΥΥΥΥΣΥΥΥΣΥΣΧΣΥΧΥΧΥΣΧΥΥΥΥΣΥΧΧΙΣ) 


This software and its documentation are provided "AS IS" and 
without any expressed or implied warranties whatsoever. 

No warranties as to performance, merchantability, or fitness 
for a particulsr purpose exist. 


In no event shall any person or organization of people be 
held responsible for any direct, indirect, consequential 
or inconsequential damages or lost profits. 


πο τὸ πὸ τὸ τὸ τὸ τὸ οὐ πὸ πὸ οὐ τὸ Pe Ὁ» 


ΠΣ ΧΙ 
ΥΥΧΥΥΧΥΥΧΥΧΧΧΥΣΥΧΧΧΙΣΥΣΧΧΧ ΧΙ 
᾿ iguration 
¢ 

bese equ 310H ; bese address of boerd 
vector_rumber equ SH 3 vector number for board 
Net_memory seg equ OocooHn ; address of ethernet memory 
net_memory_size equ 2000H 3; & bytes 
: 
3 LAN Controller Page 0 registers 
‘ 
WIC_er equ base + 0; -- control register of NIC 
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NIC_pétart equ bese + 1; -° page start register 
NIC_pstop equ bese + 2; -- page stop register 

NIC_bndy equ base + 3; “- boundary register 

WIC_tpsr equ base + ὁ; “- transmit page start register 
NIC_tberd equ base + 5; -- tranemit byte count rgtr hi 
WIC_tber? equ base + 6; “- transmit byte count rgtr to 
WIC_isr equ base + 7; -- interrupt status register 
WIC_rsar0 equ base + 8; “- remote start address rgtr lo 
NIC_rser( equ base + 9; “- remote start address rgtr hi 
wic_rberd equ base + j0; “- remote byte count rgtr lo 
WIC_rbert equ base + 11; “- remote byte count rgtr hi 
wic_rer equ base + 12; -- receive configuration rgtr 
wic_ter equ base + 13; τα transmit configuration rgtr 
WIC_der equ base + 14; -- data configuration register 
WIC_imr equ base + 15; -- interrrupt mask register 


controller page 1 registers - NIC address setup registers 
These registers are written to establish what the actual 
physical address will be. 


phys_address_0 equ base + 1; 3 physical address registers. 
phys_address_1 equ base + 2; 3 These registers are accessed 
phys_address_ 2 equ base + 3; 7 vie NIC_er bits 7,6 = 0,1. 
phys_address_3 equ base + 4; Σ LAN registers are accessed 
phys_address 4 equ base + 5; ; via cntrt bits 3,2 « 0,0. 
phys_address_ 5 equ base + 6; Σ 

wiC_curr equ base + 7; 3 only written once during init 


Controller Page 2 - Ethernet PROM ADDRESS memory 

These locations contain the "preferred" address as contained 
ἴα PROM. These will typically be copied to the physical 
address registers above (page 1). 


prom_address_0 equ bese + 0; -- station address 0 
- prom_address_1 equ base + 1; -- station address 1 
prom_address 2 equ base + 2; -- station eddress 2 
prom_address 3 equ base + 3; τι station address 3 
prom_address_4 equ bese + 4; -- station address 4 
prom_address_5 equ base + 5; -* station address 5 


Gate Array registers (note: offset of SO0H) 


Se te we 


pstr equ base + 400H; “- page start register 

pser equ base + ΔΟΊΗ; -* page stop register 

dgtr equ base + 402H; -- drq timer register 

befe equ base + 403i; -- base configuration register 

petr equ bese + 404H; -- prom configuration register 

gacfr equ base + 40S5H; -- ga configuration register 
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entri 
streg 
idefr 
damsb 
dalsb 
vetr2 
vptrt 
vptrd 
efmsb 
efisb 
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+ 406H; τι gate array (ga) control rgtr 
+ 4O7H; το ga status register 

+ 4608H; στ interrupt/OMA enfgrtn rgtr 
+ 4O9H; το OMA address register hi 

+ 4OAH; -- DMA address register lo 

+ 408H; “- vector pointer rgtr δ 

+ 40CH; °+ vector pointer rgtr H1 

+ 400H; -- vector pointer rgtr #0 

+ 40EH; -- register file access hi 

+ 40FH: -- register file access lo 


Ἢ AARREREREREARERAAREEREREREAARARAAEAETREE 


3* Ethernet (3com) Initialization Values * 
3 ees APR SRAARAARRAERRERAAEARAARAREAAKEAAEARAE 


eth_enable_reset 
eth_disable reset 
eth_access_prom 
eth_recv_ select , 
eth_lan_config 
eth_rem_OMA_burst 
eth_irq line 
eth_rem_OMA_config 
eth_xmit_buf start 
eth_recv_buf_start 
eth_recv_ buf _end 
eth_offset 
eth_recv_begin 
eth_recv_end 
eth_start_nic 
eth_nic_stop 
eth_nic_DMA config 
eth remote OMA_lo 
eth_remote_DMA_hi 
eth_packet_types 
eth_nic_mede 
eth_bndy_start 
eth_int_status 
eth_ints_enabled 
eth_sccess_page_0 
eth_access page_1 
eth_exit_mode 


nic_prx 
nic_ptx 


send 


ren er Ty 


ὃ B88 δ 8 8 5 8 888 888 ἃ 


O3h 3 enable reset 
00h 3 disable reset 
04h 3 access prom bytes 
00h ; select external Xcejver 
4M 7 8k of mem-map 1/0, w/interrupts 
08h 3 # of bytes to transfer on DMA burst 
80h 3 interrupts occur on [365 
20h 3 8k configuration for remote OMA 
20h ; begin of transmission buffer (OH) 
26h 3 receive queue (0600H) 
40h 3 20 pages, 256 bytes/page (2000H) 
2000h 7 difference between page & address 
600h 3 actual offset in RAM seg for begin 
2006h ¢ actual offset in RAM seg for end 
02h 3 start NIC 
Oth 3 stop the NIC 
48h ; local DMA operations, 8 byte bursts 
00h 3 DMA remote unused (10) 
00h : OMA remote unused (hi) 
Ofh 3 Peceive any kind of packet 
02h ; internal loopback mode 
00h : FOR NOW, DO NOT USE BOUNDRY REG! 
Offh : clear status of all ints at start 
00h 3 enable no interrupts 
00h 3 access page 0 again 
4OH 3 access NIC page 1 registers 
00h 3 exit internal loopback mode 
1 ; mask for packet receive interrupt 
2 ; mask for packet transmit interrupt 
4 ; command byte to start transmission 


Interrupt Contro(ler Comnand 


-187- 


Demonstration Project Final Report 


NET_EO! equ 60H + vector_mumber ; -- End Of Interrupt (specific) 


Ethernet controller routine specifications 


Ethnet_Init initializes a 3com Etherlink 11 board to transmit and receive 
packets via a memory mapped interface with the board located at 0€00:0000. 
The base address from which the registers are located is 310h. The init 
routine intializes the memory to zeroes before it completes. Although no 
OMA is used to transfer the data from main memory to the board’s memory 
(which is referred as remote OMA operations), there is πὸ choice but to 
use the local OMA operations (transferring bytes or words from the board’s 
memory to the board’s output fifo’s). 
LIST 


=e το οὐ fe Be Be te πο Be Oe 
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page 55,132 3 
TITLE 10 - Distributed Ada Network 10 
tee : Η 211 


sig Distribution and Copyright ἢ; }: 7:7} }17}1111 
LabTek Distributed Ada v1.0 


This Distributed Ada Runtime inherits the LabTek copyright. 
The following copyright must be included in all software 
utilizing this Ada Runtime. 


Copyright 1989 by LabTek Corporation, Woodbridge, CT, USA 


, 

ῃ 

; Permission to use, copy, modify, end distribute this 

; «software and its documentation for any purpose and without 
; fee is hereby granted, provided that the above copyright 
‘3 notice appear in ail copies and that both that copyright 
notice and this permission notice appear in supporting 

; documentation, and that the name of LabTek not be used in 
; advertising or publicity pertaining to distribution of the 
; software without specific, written prior permission. 

; Lablck makes no representations about the suitability of 
ἡ this software for any purpose. It fis provided "as is" 
without express or implied warranty. 


een eee . ee e ἡ ° ae eee ae . -. ee . . . 
Στ ΣνΣ 2 11}11111 Oisclaimer ;;;:7:7::::.:::1:211221221}}1222212211] 


=e 


This software and its documentation are provided “AS 19" and 
without any expressed or implied warranties whatsoever. 

No warranties as to performance, merchantability, or fitness 
; for a particular purpose exist. 


; Inno event shall any person or organization of people be 
; held responsible for any direct, indirect, consequent ‘al 
or inconsequential damages or lost profits. 


The 10 module provides the low_level interface to the network 
hardware and receive message buffering. 


᾿ 
; 
; This code is loaded into all processors, and adapts to the 

; the network hardware in its host. Which routines are used is 
; determined solely by the calls made from the application code 
; and the messages received. 

Η 

: 

͵ 


The 10 interface is implemented as four separate functions: 
Initialize 
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Transmit 
Receive - 
Interrupt Procesing 


The initialize function obviously must be called prior to any 
other, and establishes the interrupt vector and enables, as 
well es prepares the hardware for use. It is also responsible 
for initilizing data structures used to buffer incoming packets. 


The Transmit function is used by one task st a time, and is 
guarded by ὁ semaphore to provide mutual exclusion. Once the : 
transmit resource is granted, the data is copied into the on-card; 
buffer and sent out vise hardware commends. (Normelly, hardware 
packet acknowledge should be provided and therefore it is not 
implemented in software, even though Ethernet does not support 
hardware acknowl edge.) 


The Receive function is provided to assist in transferring the 
Gata to the requested destination. 


The Interrupt Processing handles both transmit complete and 
reception interrupts. For transmit complete, the resource is 
simply made available again by performing a V operation on the 
trasmit semaphore. For Receive interrupts, a buffer is allocated 
from ὃ linked list of fixed sized buffers. Then the incoming 
data is copied to the buffer and the distributed runtime is 
invoked to process the request. It may simply post the fact the 
message has arrived (and queue to an entry), or it may cause a 
task to resume which involves signalling (V - operation) the 
suspended task. 


Refer to individual procedure headers for parameter information 
and calling requirements. 


ver Date Description 


0.1 Nov-88 : Initial prototype 


me Be Be τὸ τὸ τὸ τὸ Be Me οὖ οὐ Me Be BH τὸ Me τὸ τὸ τὸ “ο τὸ πὸ πὸ πὸ Me τὸ τὸ τὸ Be Ὁ» 


-model large 
include DA_DEF.ASM 7 contains software definitions 
include DA_HW.ASM 3 contains hardware specifics 


public [10_Metwork_Init, 10_xmit 
public YX_READY 3 semaphore 
public IO_ALLOCATE, 10 _DEALLOCATE 
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VRTIF_Signal_I:far 


extrn 3 signal semaphore 
extrn «- VRTIF_Wait: far ; wait om semaphore “p* 
extrn = VRTIF_18259: abs ; address of 8259 
extrn VRTIF_vector_base:abs ; base of vector table 
extrn Setup:near 3 Initialize Network 1/F 
extrn NET_Receive:near 


͵ 
3; software support buffers 


buff_size equ 2048 3 bytes in local buffer 
- num_buf f equ 20 ; mumber of buffers 
eseg segment common 


org ocoox 
assume cs:cseg,ds:cseg,es:cseg,ss:sseg 


ΣΧ ΧΧΣΥΣΥΥΣΧΥΧΣΥΥΣΥΥΣΥΣΥΣΣΧΣΣΥΥΣΥΣΥΥΧΥΥΥΧΧΥΥΥΣΥΧΣΧΙΖΙ 
; WETWORK_INIT : load Interrupt Vector and clear pointers ; 
ΠΣ ΣΧ eee ere eer ereee reer eee eere ere eese eee eeey) 
10_Network_Init: 

push ax 

push bx 

push cx 

push dx 

vush ds 


; Do low level Network Interface Card Initialization 
call Setup 


; 
3; init network variables 


mov ax,cs 
πον ἀ8,8Χ 
mov (RECEIVE_PTR] ,eth_recv_begin ; receive pointer 


; Initialize Receive buffer list 


lea ax, RX_BUFF_Q 

mov (RX_BUFF_HEAD] , ax 

lea ax, RX_SUFFER ; points to actual buffers 

mov cx, num_buf f ; number to Link 

lea bx ,RX_BUFF_Q 3 points to buffer descriptors 
141t30: 

mov {bx} , ax 3 put in current buffer pointer 

lea dx, [0χ.4] Σ OX js address of next descriptor 

mov (bx+2] , dx > put it in as next pointer 

add ax, buff _size 3 pointe AX at next buffer 
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mov bx, dx 3 change descriptor pointer to next ὁ 
loop Init30 - : 
; 
; now fix up last pointer 
mov word ptr [bx-2),0 7 terminate List 
3 toad interrupt vector 
mov ax, 
mov ds, ax 
mov bx, VRTIF_vector_base+(vector_number*4) 
mov ax, offset Interrupt_Handler 
mov fox} , ax 
mov ax, cs 
mov fox+2) , ax 
; Mote: Preliminary board initialization was done in SETUP code, now 
᾿ just enable interrupts 
͵ 
mov ax, VRTIF_18259+1 
in al dx ; get interrupt mask 
ἸῸΝ oh ,OFEH 3 mask to clear zero bit 
πον εἰ Ὑϑοῖογ ταχσεῦ ; load shift count register 
rol ah,cl 
anc al,ah 7 enable level 
out dx,al 3 update controller chip 
mov ch entrt 
mov al,eth_access_page 1 ; access WIC page 1 registers 
out dx,al 
mov dx ,nic_ime 3; interrupt mesk register 
mov al ,nic_prxtnic_ptx 3 enable xmit/recv interrupts 
out dx,al 
pop ds 
pop dx 
pop Cx 
pop bx 
pop ax 
ret 
header _size equ 10 s;words:dst#3,srcs3,RCP21, priori ty=1,seqz1, (ength=! 
PEST ESESIAIAESIRIEIAET ΧΙ ΥΧΧΧΩΣΣ ΧΙ 
i; XMIT - transmit the message specified by perameter (ist ἢ 
; starting at address is at SS:bpDEF_TCP : 
Teese eter ee Tee ee 5} 1 }}}}}} 


INPUTS: 


O_Xmit: 


b2338 


mov 
mov 
ine 
stosw 
mov 


add 


mov 
mov 
jexz 
add 

xmit_10: 
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TRANSMIT CONTROL POINTER 
Number of parameters 
offset! 
segment 
length! 

oe. OC. 


cs 3 push segment cf transmit ctrl semaphore 
ax, TX_READY 

ax ¢ push offset of semaphore 

VRTIF_Wait 3; do p semaphore operation 


; put header in packet buffer 


si, (bp*OEF TCP) 3 fetch Transmit control pointer 

di, (CARD_RAM) Σ point to hardware buffer area 

cx, header_size 3 in words 

APACKET_SIZE} , ex ; initialize packet size (in words) 

cx,2 3 do not copy sequence and length fields 
movsw 


Update Sequence Number and put it in packet 


si, [981] ; fetch sequence offset 
ax, (si) 3 get sequence count 
ax 
3 put sequence count in packet 
{si] ,ax 3 Update counter ; 


skip over length field for now 


di,2 


copy the parameters into the packet buffer 


s{,0EF Parameters 3 offset from BP to parameter list 
cx, (op+si+DEF_param_count] ; number of parameters 

xmi t_20 3 if no parameters 

si,2 ; increment to actual parameter info 


cx 
cx, (bp+si+DEF_param_length]; get size of parameter (bytes) 


cx,1 3 convert to words 

(PACKET_SIZE} ,cx 3 accumutate into packet size counter 
ds 

si, (Op+si+DEF_ PARAM OFFSET]; get address of parameter 

movew 3 copy data to packet buffer 

ds 
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add si ,OEF_param_descriptor ; go to next parameter descriptor 
pop ex : 3 get perameter count back 
loop xmit_10 


, 
3 Now all parameters have been copied in, now insert length field 
‘ 
Xmit_20: 

les di, (CARD_RAM] ¢ point to hardware buffer area 

add di ,data_length 3 add offset to data length field 

mov ax, [PACKET_S1ZE] 

stosw 3 stick in PACKET length 
EP eERERSESEOS OREO USES ERS E STATE SER ER EER ER EEE ERAT ER TREE AER E REET R TREAT AE 
3; Setup NIC registers to begin transmission H 
; Must prevent a RECEIVE interrupt from arriving, which would interfere : 
3; with the registers being updated for Transmission. - 
EPPO ReREE OO SO PESOS OSEREPSOSOSL OSE E SETAE ELIE LISLE RTE E ATO ER TEEPE TATRA 
; load start address of packet 

pushf 3 save interrupt status 

eli : 3 disable any interrupts 

mov dx ,nic_er 3 select Page 0 

mov al,eth_access_ Page 0 

out dx,al 


mov dx ,nic_tpsr ; page start register 
mov al,eth_xmit_buf_start ; transmit pege at 0C00:0000 
out dx, al 


; load length of packet : 
mov ax, (PACKET_SIZE} 


shl ax, 1 3 convert word to byte count 
mov dx, ,nic_tberd 

out dx, at 

mov dx, nic_tbert 

mov δὶ δὴ 


out ax, al 
; start transmit 


mov dx, nic_er 

mov al,send 3 command to initiate transmission 
out dx, al 

popf ; restore interrupt status 

ret 


Currently, this must have a stack freme similar to other vendor 
interrupt routines so that the interrupt-mode Signal routine will 
be able to find the interrupt return eddress and status 
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Interrupt_Handler label far 
push = bp 
mov bp, sp 
push ax 
push bx 
push cx 
push dx 
push si 
push di 
push ds 
push es 


; Setup data segment 


mov ax,seg cseg 
mov ds, ax 


First fetch fnterrupt status, and clear interrupt request 


mov dx, nic_er 3 select Page 0 

mov at,eth_access_Page_0 

out dx,al 

mov dx ,nic_isr ; look at interrupt status register 
in al,dx 

mov CISR] ,ax 3 save status 

out dx,al 3; clear interrupts 


we 


; Clear the 8259 Interrupt Request 


mov al ,NET_EO! 3 issue EO! to interrupt controller 
mov dx, VRTIF_18259 
out dx,al 


; check for receive interrupt 


we 


test [158] ,nic_prx ; see if receive interrupt 
iz Check_Xmit 


Receive complete interrupt, process incoming packet 

NOTE: since this is done inside the interrupt routine, interrupts 
are disabled, and therefore there is no interference from possible 
receive interrupts. 


we Se me Ne πὸ te 


Receive: 


Allocate a buffer, and transfer dats to the buffer 
after the following call, the buffer descriptor is in ΒΧ. 00 NOT DESTROY Bx! 


-“. Be me we 
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fs 


call 


10_Allocate 
ax,cs 

eS, ax 

di, {bx] 

3i, [CARD_RAM} 
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“destination segment is CS 


destination offset is buffer at 8. 
source is ethernet RAM 


x 


si,cs:(RECEIVE_PTR]; add current receive buffer pege address 


al,al 
ax, eth_offset 


fetch status into AL, NEXT PTR in 


to AK 


zero low byte, leaving a new pointer 


correct for memory vs page offset 


es: (RECEIVE PTR) ,ax; get ready for next reception 


si,2 


skip over receive byte count 


3 SI now points to first part of transmitted packet 
ax, (sivdata_length] ; get size of valid packet im WORDs 


mov 


me Me 8s te 


mov 
RECVO10: 


RECVO20: 


RECVO30: 


re en ee Ty 


call 


dx, 80H-2 


ἌΧ, dx 
REecvo20 
dx , ax 


ex, ax 
movsw 


si,eth_recv_end ; 


RECVO30 


si,eth_recv_begin; 


ax, dx 
RECVO4O0 
dx, 80H 
RECVO10 


ax,cs 
ds , ax 


NET_Receive 


. 
΄ 
. 


Φ 
, 
. 
e 
. 
’ 


page size in words (reduced to ge 
see if more than a page 
otherwize only move the remaining 
do the transfer 

see if at end of hardware buffer 


reset pointer to begin 


Now transfer memory from hardware buffer pages to software buffer. 
Note that the buffer will wrap around at 4000H back to 2600. 


t aligned) 


reduce total count by those moved 


finished if so 
keep page alignment 


restore data segment 


Call Receive portion of Distributed Runtime code to determine 
what should be done with the newly arrived packet. 


Check to see if any more work to do, if so then skip clearing 
the interrupt so that another interrupt will occur imediately 


scheduler). 


Note that a limitation in the Ethernet hardware results in 
ἃ possible race condition here. 


cli 
mov 


dx ,nic_er 


; 
;Σ upon enabling interrupts (possibly after a trip through the 
: 
; 
: 


reduce chance of race (jn case VR 
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mov al,eth_access Page 1 ; select page T 

out dx,al 

mov dx, nic_curr ; get current page register 

tn al ,dx 3 fetch current page register 

mov ah,al 3 build memory address 

xor αἱ αἱ 

sub ax,eth_offset ; correct for NIC displacement 
emp ax, (RECEIVE_PTR); check if our pointer is the same 
jz Check_Xmit 3 if no work, don’t print notice 


this will result in an immediate re-interrupt 
as soon 85 interrupts are enabled 
(which meens after scheduling event) 


’ 
3; Now check for transmit complete interrupt 
; 
Check_xXmit: 
test {ISR},nic_ptx ; check for packet transmitted 
jz EO! 
; 
; Transmit complete, first clear interrupt request, then signal semaphore 
; 
Transmit: 
push cs 3 Segment of semaphore 
lea ax, TX READY ; offset of semaphore 
push ax . 
call VRTIF_Signal_I ; signal completion 
EO!: 


ESSSII 888 
δε πε 85 9588 


ΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣ 111 
; TO_ALLOCATE - Allocates next buffer from Avail list : 
Ἢ Return ΒΧ pointing to buffer queue index. ; 
7 By design, the buffer should queue should never be empty. 7 
; Destroys AX , BX has new descriptor pointer : 
PPPOE RAEESSOSOOSISLET SESE R IP OTILSIR SESE IESE SITTER TERT ER Teer ieee 
1O_ALLOCATE: 


3 fetch head pointer 


3; see if emty 


3 go on if not 
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bx, [RX_BUFF_HEAD) 


bx, bx 


10_ALLOC10 


cli 
mov 
jnz 


or 


we ee νῷ te te 


ΓῚ 
ea 
© 
ω 
οι ᾿- 
— & ee 
iy eo ee 
bd +. .ω 
ee 
3B ὃς 
- ΕΣ 
-- os 
QQ = oe 
re ae oo 
— ce 
Φῳ © “" 
cw. w en 
“--“-..Γ on 
8. Ow eo 
es 
ε 8 “. 
~ © ee 
xe os 
2 - x oo 
ee 
δὲ Σ 
£ om 
8 Ω -«- = ce 
δ’ « «» se 
ε ω .“. 
Φ - a 2 se 
oe 
on om om em +. 


ax, [bx+DEF_NEXT_PTR} 
{bx+DEF_NEXT_PTR1, ax 


(RX_BUFF_HEAD] , ax 
ax, ax 


3 


By design, the buffer should queue should never be full. 


Takes BX pointing to buffer descriptor. 


popft 
int 
mov 
mov 
xor 
mov 
popf 
ret 
cee 


Normally, might raise storage error here, but design prevents 


exceeding buffer cepacity unless there is some code flaw. 
Remove buffer descriptor from free list 
10_DEALLOCATE - Deallocates buffer into Avail list 


10_ALLOC10 
ῃ 


“ “τ σῷ σ᾿ 


. 
Γ 
. 
a 
Π 
Ω 
, 
° 
, 
. 
e 
. 
, 
Φ 
’ 


make this entry new head 
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3 put behind this entry 
; interrupt status register 
3 packet size 


3 get head of list 


1, bx 


(bx+DEF_NEXT_PTR] , ax 


BUFF _HEAD 


ax, (RX_BUFF HEAD] 
(RX_| 
Ow 


WEXT_PTR 
end record; 


10_DEALLOCATE 
Data AREA 
align 4 
PACKET_SIZE 
BUFFER QUEUE STRUCTURE 
record 
GUFFER_OFFSET 


; 
TSR 
4 
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Φιοφοοοφοφοροοοφοοφ φοοοφοφροςφοσθοσδυ 
Ιϑιρρννϑνϑθθυϑιεδιν δι εθνμδεθνενϑῆν ΄ 


CARD_RAM 
RECEIVE_PIR 


me Me πο οὐ 


TX_READY dw 
- 
cha 

RX_BUFF_HEAD ὅν 

RX_SUFFER db 

RX_BUFF_Q dw 

cseg ends 


sseg segment STACK 


address of ram buffer on enet card 
points to current next page to rcv 


The following semaphore is used to provide mutual exclusion to the 
transmit side of the Ethernet card. 


1 : semaphore count 
0 Σ task value 

0 ; task velue 

(7) 


mum_buff dup (buff_size dup (7)) 
ram_buff dup (2 dup(7)) ; (BUFFER_PTR, NEXT_OESC_PTR) 


che 100 dup (0) 


sseq ends 
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page 55,132 
TITLE LINK - Distributed Ada Linkage Module 
eae : ? 


= Se 
mf 
mise 


ΣΣΣΣΣΣ ΣΙ; Distribution and Copyright ΣΣΣΣΣΣΣΣΣΣ 2111) 
Derivation : LabTek Distributed Ada V1.0 


This Distributed Ada Runtime inherits the Labfek copyright. 
The following copyright must be included in all softwere 
utilizing this Ada Runtime. 


Copyright 1989 by LabTek Corporation, Woodbridge, CT, USA 


Permission to use, copy, modify, and distribute this 
software and its documentation for any purpose and without 
fee is hereby granted, provided that the above copyright 
notice appear in all copies and that both that copyright 
notice and this permission notice appear in supporting 
documentation, and that the name of LabTek not be used in 
advertising or publicity pertaining to distribution of the 
software without specific, written prior permission. 
LabTek makes no representations about the suitability of 
this software for any purpose. It is provided "as is” 
without express or implied warranty. 


This software and its documentation are provided "AS IS" and 
without any expressed or implied warranties whatsoever. 

No warranties as to performance, merchantability, or fitness 
for a particular purpose exist. 


Me Me οὐ τὸ οὐ Be οὐ τὸ τὸ το Ne fe Me Me πὸ τὸ πὸ το πὸ Ne πὸ Be ὁ Fe Me Fe πὸ Me Be πὸ Me Me “Ὁ 


In no event shall any person or organization of people be 
held responsible for any direct, indirect, consequential 
or inconsequential damages or lost profits. 


This code is code that would be generated by the Compiler/Linker 
and Distributor. It is kept separate from the runtime "routines" 
to delineate the generated/runtime boundry. 


This code is Linked to the Ada application via (hand) editing 

of runtime cal(s within the generated Ada program. Essentially, 
a call {s made from each of the rendezvous operations in the 
generated call to the respective support code here, then a return 
is made beck. Since the compiler does not supply information 


me Se Be τὸ Me Be fe το Be τὸ το Be πὸ τὸ Me te 
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on the parameters in the code (it is implicitly maintained by 
the compiler amoung entry call/accept pairs), ὃ Tittle support 
code is placed here to provide the information. Normally 8 
compiler that supports distribution would put this in line. 


The support code then calls general purpose (although prototype) 
routines to implement remote entry, accept, select, and error 
mechani sms. 


Each packet header is statically formed and placed in this 
module to be reference by the TRANSMIT CONTROL PTR (TCP) used in 
the runtime call perameter list. This rea.ces the overhead 
associated with packetizing the data. These packet headers 
could be generated by the compiler/linker/distributor and 
optimally would be placed fn the controtler card memory at 
elaboration time so that loading of header data would be 
necessary. 


΄ 


Ver Date Description 


0.1 Nov-88 : Initial prototype 


me τον τὸ ον ον τὸ τὸ τὸ τὸ τὸ τὸ τὸ SH Me Me Be τὸ πο Me Be ὁ “ὁ πὸ “ὁ 


include 0A_OEF.ASM 
model large 
extrn = Initialize: far 


extrn remote_entry:far, local_entry:far 

extrn Any_select:far, remote_accept:far, remote_end_accept: far 
extrn local_end_accept: far 

extrn remote_elab_start:far, remote_elab_ wait: far 

extrn remote_elab_continue: far 

eatrn I0_DEALLOCATE:near 

extrn outchr:near 


cseg segment common 


wee me «Ὁ 


Lengths of rendezvous data parameters 


ROCKET_MSG_TYPE_LENGTH eu 202 
ROCKET _GUIDE_MSG_TYPE_LENGTH equ [22 
TARGET_MSG_TYPE_LENGTH equ 1002 


Φ 
e 
. 
, 


Rendezvous parameter offsets 
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. 
a 


NEXT_ROCKET_MSG equ 1908 3 offset from BP 
CONTROL_GUIDE_MSG equ 386 3 offset from BP 
ROCKSUP_GUIDE_MSG equ 3% 3 offset from BP 
ROCKSUP_REPORT_MSG equ -212 3 offset from BP 
TARGET _MSG equ «1012 ; offset from BP 


assume cs:cseg,ds:cseg,es:cseg 


The following jump table provides (static) control transfers from the 
Ada application code to the respective support code located here 


we Se te “ὦ 


align 8 


im Init prior to elaboration 


align 8 

jmp Elaborate Start 
align 8 

imp Elaborate_Wait 
align 8 

jmp Elaborate_Continue 


to synchronize elaboration 


will wait for elaborate sync. 


to acknowiedge completion 


align 8 

imp get_report_entry 
align 8 

jmp put_report_entry 
align 8 

imp  report_buf_select 
align & 

imp get_report_end_eccept 
align 8 

imp put_report_end_eccept 


catled by Rocket.Controt 


ee 


called by Simulate.ROL.Rocket_Support 


called by Simulate.RDL.Report_Buf 


called by Simulate.RDL.Report_Buf 


called by Simulate.ROL.Report_Suf 


ory 


align 8 

imp get_guide_entry 3 called by Simulate.RDL.Rocket_Support 
align 8 

jmp guide_buf_select 3 called by Simulate.ROL.Guide_Buf 
atign 8 


imp put_guide_entry called by Rocket.Control 


stign ὃ 

jmp get_next_target_entry ; called by Target.Track 
align 8 

imp get_next_terget_eccept ; called by Simulate.Sensor.Targ Support 
align 8 

imp get_next_target_end_aeccept; cailed by Simulate.Sensor.Targ_ Support 
align 8 

imp get_quide_end_ accept 3 called by Simulate.RDL.Guidebuf 
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align 8 
imp = put_guide_end_accept 3 called by Simulate.ROL.Guidebuf 
align 80H 
LEE TEER ERS ITISELERILAIISIPETE SITET PEER EESAIIL TESTER R TREE E TTT ETE ee 
e 
; INIT to initialize the network hardware 
; 
Init: 
push ds 
mov ax,cs 
mov ds, ax 
call Initialize 
pop ds 
retf 


᾿ 
; ELABORATE_START 

; The main program calls this routine to send a "βῖγι" to the 
; bravo processor. The remote_elab start routine will suspend 
3; ἴδε main program until the continue is received from the 

; elaborating processor. 

; 

E 


laborate_ Start: 
pusa ds 
mov ax,cs 
mov ds ,ax 
xor ὌΧ, ax 3 NO parameters 
push ax 
lea ax,TX_elaborate_ begin ; transmit control ptr 
push ax 
lea ax ,Main_TCB 3 task_id 
push ax 
call remote_elab start 
add sp,6 7 fix up stack 
; Normally, test AX for NZ to see if there was an elaboration 
; error on the renote processor, however it will be ignored 
;Σ ἴη this case. 
pop ds 
retf 
ΠΥΧΧΧΥΥΥΥΧΥΧ ΣΧ ΧΧΧΧΧΧΧΧΣΥΣΣΥΧΧΧΧΧΧΧΣΣΧΧΧΧΧΧΧΧΣΧΧΧΧΧΧΧΧΣΣΧΧΧΧΧΙΖΙ 
; 
; ELABORATE_WAIT : Suspends a task until it fs given the signal 
7 to continue from the elaborating processor. 
Elaborate_Wait: 
push ds 


mov ax,cs 


Demonstration Project Final Report 


mov ds, ax = 
lea ax, Main_TC8.ENTRY1_Q 3 put main entry queue (pseudo) 
push ax 
lea ax, Main_TCB 
push ax 3 put main TCS as task_id 
call remote_elab wait 
add sp,4 
pop ds 
retf 
EPEREPERIERSEA EU ISERTESTORITITETISE TEE SEEA ERE TIRITEAEER TET TT 
;  ELABORATE_CONTINUE : Notifies the elaborating processor that 
; the specified elaboration in complete and 
: that it can continue elaboration of other 
: units. 
Elaborate Continue: 
push ds 
mov ax,cs 
mov ds , ax 
xor ax, ax ; MO perameters 
push ax 
lea ax, Main_TCB.ENTRY1_Q 3 pass entry queue in place of TCP 
push ax 7 RTE will deallocate incoming buffer 
lea ax ,Main_TcB 3 and calling task id 
push ax 
call remote_eiab_continue 
edd sp,6 3 remove perameters 
pop ds 
retf 


get_report_entry: 3; called by Rocket.Control 


push ds 
mov ax,cs 
mov ds, ax 
mov al ,/R! 
call outchr 
mov al,’G’ 
call outchr 
mov al,’ 
call outchr 
; 
; Push peremeters for remote rendezvous entry 
xor ax, 8x 3 no IN perameters, set count to zero 
push ax 
lea ex, TX_report_begin_entry 3 transmit control ptr 
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push ax 

lea ax,Control_TCB ; rocket.control task 
push ax ;Σ push task_id 

call remote_entry 

add sp,6 ; clean up stack 


mov bx, word ptr [Control_TCB+OEF_TCB_REPLY] ; get reply pointer 
3; Copy out parameter, (BX) points to buffer descriptor 


lea di, [bp>+NEXT_ROCKET_MSG} ; point to NEXT_ROCKET_MSG 
mov si, [bx] 3 get address of buffer 

lea . si, (si+data_field) ; get pointer to data in packet buff 
mov cx, ROCKET_MSG_TYPE_LENGTH 


shr ex,1 ; word count 

mov ax,SS 

mov eS, ax 

pushf 

eli 3 

rep movsw 

popf 

call 10_Deallocate ; Deallocate receive buffer 

pop ds 

retf 
ΣΧ errr er ere vases sere ee eee eR eee reese ee eeeeeeee eee eeeeeeeee ieee) 
; NOTE: STACK FRAME LOCATIONS ARE POSITION DEPENDENT 
report_buf select: ; called by Simulate.ROL.Report_Buf 

push ds 

mov ax,cs 

mov ds, ax 

mov al,’R’ 

call outchr 

mov δὶ," 5! 

call outchr 

mov al,’ ! 


catl outchr 


lea ax ,Reportbuf_TCB.ENTRY1_Q 3 get report 

push ax 

lea ax,Reportbuf_TCB.ENTRY2_Q 3 put report 

push ax 

mov ax,2 3 number of entries (fixed) 

push ax 

lea ax ,Reportbuf_TCB 3 task_id 

push ax 

call Any_select parameter pointer & selector on stack 


edd sp,8 3 Pestore stack 


=e 
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place return parameters on stack 


push bp 

mov bp. sp 

mov [Ὀρ.8] , ax 
mov (bp+ 10) , bx 


put selector on stack 
put offset of data pointer on stack 


mov ax,cs 

mov (bp 12) , ax 3 put segment of data pointer on stack 
pop bp 

pop ds 

retf 


get_report_end_accept: 3 called by Simlate.ROL .Report_Buf 

push ds 

mov ax,cs 

mov ds, ax 

mov ‘al,‘e’ 

call outchr 

mov δὶ," Α' 

call outchr 

mov al,’ ! 

‘call outchr 

mov ax, ROCKET_MSG_TYPE_LENGTH 3 length 
push ax 


3 put address of data buffer οὐ stack (first and only parameter) 


push word ptr es: (bx] ; segment 

push word ptr es: [Ὦχτ 2] 3 offset 

mov ax, 3; Mumber of out parameters 
push ax 

lea ax ,Reportbuf_TCB.ENTRY1_@ 3 entry_Id 

push ax 

lea ax, Reportbuf_TC8 3 task id 

push ax 

call remote_end_accept 

edd sp,12 3 Cemave parameters from stack 
pop ds 

retf 


pUt_report_end_accept: ; Called by Simulate.ROL Report _Buf 
push ds : 
mov ax,cs 
mov ds , ax 
mov al,’ 
call outchr 
mov δὶ, "Α’ 


call outehr 
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al,’ ! 
outchr 
ax, Reportbuf_TCB.ENTRY2_Q 
ax 
local_end_accept 
3 Temove parameter 


put_report_entry: ; called by Simulate.ROL .Rocket_Support 

ds 

ax,cs 
ds ,ax 
al,’R* 
outchr 
al,’P! 
outchr 
al,’ ͵ 
outchr 


ss segment of data area 
ax, (bp+ROCKSUP_REPORT_MSG] offset of data 
ax 
ax, Reportbuf_TCB.ENTRY2_Q dst entry ID 
ax 
ax, Reportbuf_TCB dst task id 
ax 
ax, Rocksup_TCB src task id 
ax 
local_entry 
restore stack 


j segment of data area 
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lea ax, (bp+ROCKSUP_GUIDE_MSG) ; offset of data 


push ax = 

lea ax, Guidebuf_TCB.ENTRY1_@ 3 dst entry ID 
push ax 

lea ax, Guidebuf_TCB 3 dst task id 
push ax 

lea ax, Rocksup_TCB ¢ sre task id 
push ax 

call locat_entry 

add sp,10 3 restore stack 
pop ds 

retf 


guide_buf_select; 3 ca | 
push ds 
κὸν ax,cs 
mov ds, ax 
mv al, 6! 
call outechr 
mov δὶ," 5! 
call outchr 
mov al,’ ! 
call outchr 
mov ax,1 ; slways 1 entry (put_next) 
mov cx, (bp- 134) 3 check MSG_COUNT 
cmp cx,0 
jle gbs 10 3; if guard closed 
ine ax 3; allow two entries 
lea bx, Guidebuf_TC8 .ENTRY1_@ 3 Get_next_guide 
push bx 
; put_next_guide is always open 
gobs 10: 
lea bx, Guidebuf_TCB.ENTRY2_Q 3 Put_next_guide 
push bx 
push ax 3 number of entries 
lea ax ,Guidebuf_TCs 3 task_id 
push ax 
call Any_select j parameter pointer & selector on stack 
pop cx 3 remove task_id 
pop cx 3 get rumber of entries 
shl ex,1 3; two bytes per entry 
add sp,cx 3; remove local stack frame 


place return parameters on stack 


we “ὁ Ἢ 


push = bp 

mov bp, sp 

mov (bp+8! , ax 3 put selector on stack 

mov Cope10) , bx 7 put offset of data pointer on stack 
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3 put segment of data pointer on stack 


(bp+12] , ax 
bp 


ax,cs 


ds 


retf 


mov 
mov 
pop 
pop 


-ROL.Guide_Buf 


3 called by Simulate 


de_end_accept 


get_gui 


‘TCB.ENTRY1_Q 
Accept 


ax, Guidebuf 


ax 
Local_End_Ace 


al,'G* 
outchr 
al,’e’ 
outchr 


push 
mov 
call 
mov 
call 
lea 
push 
catl 
add 


3 remove parameter 


sp,2 


ds 


retf 


pop 


ROL Guide δι 


; called by Simulate 


accept: 


end_acc’ 


put_gui 


3; Mumber of out parameters 


3 entry_ID 


Guidetuif_TCB.ENTRY2_9 


al,‘G’ 
outchr 
al,'p! 
outchr 
al,’ ¢ 
outechr 
ax,0 
ax 

ax, 

ax 


mov 
call 
mov 
call 
mov 
call 
mov 
push 
lea 
push 


_ id 


leave space normally task 


. 
‘ 


ax 


push 


femove parameters from stack 
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ept 


3 called by Rocket .Control 


remote_end_acc 


sp,6 
ds 


Y 


call 
add 
pop 
retf 
de_entr 
push 


put_gui 
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al,‘G! 

outchr ΄ 
αἱ, "Ρ' 

outchr 

al,’ ! 

outchr 

ax, ROCKET GUIDE_MSG_TYPE_LENGTH 3 length 
ax 

85 

ax, [bp+CONTROL_GUIDE_MSG) 

ax 

ax,1 

ax 

ax, TX_guide_begin_entry 

ax 

ax, Controt_TcB 

ax 

remote_entry 

sp, 12 

bx, word ptr (Control_TCB+DEF_TCB_REPLYJ 
10_Deal locate 


me Me 


offset 


1 in parameter 


ae 


tx control pointer 


ae 


task id 


we 


restore stack 
get reply pointer 
no OUT entry params 


ax, ax 3 no in perameters 

ax 

ax,TX_track_begin_entry ; transmit control ptr 
ax 


ax, Track_TCB 7 task_id 

ax 

remote_entry 

3p,6 3; clean up stack 


bx,word ptr (Track _TCB+DEF_TCB REPLY] ; get reply pointer 


Copy out parameter, (8X) points to buffer descriptor, δῖ to control block 


lea 
mov 
lea 


di, (bp+TARGET_MSG) 3 point to TARGET_MSG 
si, (bx) ; get actual buffer address 
si, (siedata_field) 3 point to packet data 
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mov 
shr ex,1 3 make nord count 
mov ax,$s 
mov es,ax 
pushf 
eli 
rep movsw 
popf 
call 10_Deal locate :  Deallocate receive buffer 
pop ds 
retf 
PEP PSRREEESTSEOCEORVESEE ES ERE E TEER ERUAERERERTIAERTRTEAEASE REET REY 
jet_next_target_accept: ; called by Simulate.Sensor.Targ Support 
push ds 
mov ax,cs 
mov ds, ax 
mov al,'T! 
call outchr 
mov al,’a’ 
catl outchr 
πον δἱ,! ! 
call outchr 
lea ax, Targsup_TCB.ENTRY1_Q ;Entry Queue of interest 
push ax 
lea ax, Targsup_TCB : our task id 
push 8x 
call remote_accept ; returns: ES:8X-data ptr 
add sp,4 j adjust stack back 
pop ds 
retf 
PEP ΣΧ ΧΥΥΣΥΧΧΥΥΥΥΣΧΥΣΥΣΥΧΥΥΣΥΧΥΧΥΧΥΧΥΧΣΥΥΣΥΣΥΧΥΧΥΧΥΣΧΧΧΣΣΧΧΣΥΥΣΙΙΙ 
get_next_target_end_accept: ; called by Simulate.Sensor.Targ_ Support 
push ds 
πον ax,cs 
mov ds ,ax 
mov al,‘T’ 
call outchr 
mov al,’b’ 
call outchr 
mov al,’ ! 
call outchr 
mov κχ, TARGET_MSG_TYPE_LENGTH 
push ax 
3 put address of data buffer on stack (first and only parameter) 
push word ptr es: (bx) ; segnent 
push word ptr es: (bx+2) 3 offset 
mov ax,1 7 Murber of out perameters 
push ax 
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lea ax, Targsup_TCB.ENTRY1_Q 3 entry_Id 

push ax - 

push ax 3 leave space normally task_ id 
call remote_end_accept 

add sp,12 ; remove parameters from stack 
pop ds 

retf 

align 80H 3; keep addresses from changing 


The following data structures are used to generate and respond to 
data packets. 


type TRANSMIT_CONTROL_TYPE is record 
DESTINATION : NET_ADDR; 


SOURCE ς NET_ADOR; 

RCP 3 RECEIVE_CONTROL_PTR; -- Receive Control Field 

PRIORITY 3 PRIORITY_TYPE; 

SEQUENCE PTR : SEQUENCE_TYPE; -- offset to sequence counter 
end record; 


type REPLY MODE_TYPE is (NO_REPLY, REPLY); 


type RECEIVE_CONTROL_TYPECREPLY MODE : REPLY _MODE_ TYPE) is record 
COMMAND s WORD range 0..8; -+ see command table below 
PROC_ID 3 WORD; “- processor ID 
TASK_ID s WORD; 
ENTRY_IO : 
case REPLY is 
when TRUE => 
TX_CONTROL : TRANSMIT_CONTROL_TYPE; 
wher, FALSE => 
null; 
end case; 
end record; 


me το οὐ Me we ὧν Be Me ὧν τὸ te te τὸ τὐ Be ὧν τὸ οὐ τὸ τὸ πὸ τὸ Be τὸ οὐ He Me τὸ te τὸ te 


TX_elaborate_begin: 


DEF_bravo_eddress <> 
OEF_alpha_eddress <> 


che OFFSET RX_elaborate_begin 3 RECEIVE CONTROL 

du 0 ; priority 

cu OFFSET BRAVO_SEQUENCER 3 sequence pointer 
RX_elaborate_begin: 
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DEF_elab_begin 
DEF_pid_bravo 
offset Main_TCB 
2] offset Main_TCB.ENTRY1_O 
3 reply Transmit control record 
OEF_alpha_address <> 
DEF_bravo_address <> 
Gu OFFSET RX_elaborate_end 
cw 0 
oF OFFSET ALPHA_SEQUENCER 


Gu 
Get 
Gu 


RX_elaborate_end: 
DEF_elab_end 
DEF_pid_alpha 
offset Main_TCB 
offset Main_TCB.ENTRY1_Q 


Peer eee ene ssecresoenaesesseeseeesressesesenesessces 
eee oeeteereesreezgeecraeevnersceeeeeseeeeaeerressese 


TX_report_begin_entry: 
DEF_bravo_address <> 
OEF_aipha_address <> 
dw OFFSET RX_report_begin_entry 
dw 0 
dw OFFSET BRAVO_SEQUENCER 


RX_report_begin_entry: 
te DEF_request_entry 
dw DEF_pid_bravo 
dw offset Reportbuf_TCa 
cw offset Reportbuf_TCB.ENTRY1_| 
3 reply 
DEF_alpha_address <> 
DEF_bravo_address <> 
dw OFFSET RX_report_erd_entry 
ce 0 
du OFFSET SRAVO_SEQUENCER 


RX_report_end_ entry: 
DEF_accept_complete 
DEF_pid_alpha 
offset Control_TCcB 


ον 
che 
dee 


Seder ert emaseseneseeseceessorerassasrear ser eesese 
Oveeacreoeoseerteorteseteosvedeseeeecreaseseeeonere 


TX_gquide_begin_entry: 
DEF _bravo address <> 
DEF_alphe_address <> 
ce OFFSET RX_guide_begin_entry 
du 0 
au OFFSET BRAVO_SEQUENCER 


we fe οὐ fe 


efaborate begin COMMAND 
dest. Proc ID (bravo) 
dest. Task ID (Main) 
entry = elaborate 


RCP 
priority 
sequence pointer 


COMMAND = Elaborate End 
dest. Proc ID (alpha) 
dest. Task 1D (MAIN) 


COMMAND = begin entry 
priority 
sequence pointer 


COMMAND = begin entry 
dest. Proc 10 (bravo) 
dest. Task ID (Report_Buf) 
entry = GET_NEXT_REPORT 


COMMAND = acceot complete 
priority 
sequence pointer 


COMMAND « accept complete 
dest. Proce ID (alpha) 

dest. Task ID (Control) 
caller entry is not required 


COMMANO = begin entry 
priority 
sequence pointer 
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RX_guide_begin_entry: 


cu 
cha 
du 
dw 
3 reply 


DEF_request_entry 
DEF_pid_bravo 
offset Guidebuf_TC8 


offset Guidebuf_TC8.ENTRY2_Q 


DEF_alpha_address <> 
OEF_bravo_address <> 


cu 
du 
dw 


OFFSET RX_guide_end_entry 
0 
OFFSET ALPHA_SEQUENCER 


RX_guide_end_entry: 


cu 
Gu 
ὅν 


OEF_accept_complete 
OEF_pid_alpha 
offset Control_TCB 


TX_track_begin_entry: 
DEF_bravo_address <> 
OEF_alpha_address <> 


Cw 
dw 
[ 


OFFSET RX_track_begin_entry 


Q 
OFFSET BRAVO_SEQUENCER 


RX_track_ begin_entry: 


du 
dw 
dw 
ou 

reply 


DEF _request_entry 
DEF _pid_bravo 
offset Targsup_TCB 


offset Targsup_TCB.ENTRY1_Q 


DEF _alpha_address <> 
DEF _bravo_address <> 


Gu 
ὧν 
ce 


OFFSET RX_track_end_entry 
0 
OFFSET ALPHA_SEQUENCER 


RX_track_end_entry: 


ALPHA_SEQUENCER dw 
BRAVO_SEQUENCER dw 


ὅν 
ou 
cu 


DEF_accept_complete 
DEF _pid_alpha 
offset Track _TCB 


we Se τὖ “Ὁ 


we te we 


we Me me Ὁ te 


“ο τὸ "4 


ss ee we fe 


΄ 


COMMAND = begin entry 
dest. Proc ID (bravo) 
dest. Task ID (Guide Buf) 
entry = PUT_NEXT_GUIDE 


RCP COMMAND = accept complete 


priority 
sequence pointer 


COMMAND = accept complete 
dest. Proce ID (alpha) 
dest. Task ID (Control) 
caller entry not required 


COMMAND = begin entry 
priority 
sequence pointer 


COMMAND = begin entry 
dest. Proc [0 (bravo) 
dest. Task 1D (Targ_Sup) 
entry 5 Get_Target_Msg 


COMMAND = accept complete 
priority 
sequence pointer 


COMMAND = accept complete 
dest. Proc [Ὁ (alpha) 
dest. Task 1D (Track) 
caller entry not required 
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For now, all tasks have at most two entries, therefore this is 
static. ᾿ 


The ΤΟΒ contains a Synchronize semaphore which is used to 
suspend itself and wait for a signal from another task. 

This is followed by a list of entry records. Each entry record 
contains: 

- Awaiting flag used by the accepting task to indicate that it 
has suspended waiting for a call on this entry (and possibly 
others). 

- A buffer List Pointer, This points to the buffer descriptor 
for the first caller to this entry. The buffer descriptor 
provides the actual buffer address and a link to the next 
descriptor. This provides the FIFO queve for each entry. 


In the case of the MAIN program, Entry! is used for elaboration 
control of library units. 


΄ 


cB struc 
SYNC_SEMAPHORE OW: 3 dup (0) ; to synchronize rendezvous 
ENTRY1_Q Ow 2 dup (0) ; waiting flag, next ptr 
ENTRY2_Q DW 2 dup (0) ; waiting flag, next ptr 
REPLY_PTR Dw 0 ; pointer to replies 

TCB ends 

Main_TCB cB © 


Targsup_TCB ¥cB <> 


Rocksup_TCB TCB ° 


Guidebuf_TCB τὸ «» 


Reportbuf_TCB TCB <> 


Track_TCB 1B 


Control _TCB TCB <> 


end 
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page 55,132 
TITLE RTE - Distribted Ada Runtime Module- 
tee : ἢ 


333 Distribution and Copyright ΣΣ:ΣΣΣΣΣΣ}}}17:111:)1 
LabTek Distributed Ada V1.0 


This Distributed Ade Runtime inherits the LabTek copyright. 
The following copyright must be included in all software 
utilizing this Ada Runtime. 


Copyright 1989 by LabTek Corporation, Woodbridge, CT, USA 


Permission to use, copy, modify, and distribute this 
software and its documentation for any purpose and without 
fee is hereby granted, provided that the above copyright 
notice appear in all copies and that both that copyright 
notice and this permission notice appear in supporting 
documentation, and that the neme of LabTek not be used in 
advertising or publicity pertaining to distribution of the 
software without specific, written prior permission. 
LabTek makes no representations about the suitability of 
this software for any purpose. It is provided “as is 
without express or implied warranty. 


This software and its documentation are provided "AS IS* and 
without any expressed or implied warranties whatsoever. 

No warranties as to performance, merchantability, or fitness 
for a particular purpose exist. 


In no event shall any person or organization of people be 
held responsible for any direct, indirect, consequential 
or inconsequential damages or lost profits. 


Remote_Entry, Remote Select, Remote_Accept, Remote_End_ Accept, 
Remote_Elab_Start, Remote _Elab_ Wait, Remote _Elab Continue. 
Local _End_Accept 


ee το ee Me Me τὸ Se "ο νόὸ Be Me Be Me το Me Me Be Me MH Me He MR τὸ τὸ Me Be οὖ Me τὸ πο τὸ τὸ πὸ τὸ Me Me Be He Me τὸ τὸ το Be 86 ο Me το το fe 
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é - : 
; Ver Date Description ᾿ ; 
; : 
; 0.1 νον-88 : Initial prototype : 
; : 
; ῃ 
: ἢ 
ΠΥΧΧΣΧΧΣΣΧΣΧΧΧΣΧΣΣΧΣΣΧΧΣΣΧΧΧΧΟΧΣΣΧΣΧΧΣΧΥΣΧΣΧΧΧΧΧΣΧΧΧΙΙΙ 

emodel large 

e public Initialize 

public Remote_Entry, Local_Entry, Any_Select 

public Remote_Accept, Remote_End Accept, Local_End_ Accept 

public Remote_Elab Start, Remote _Elab Wait, Remote_Elab_ Continue public NET Receive ; calle 


3 Vendor Runtime Services 
extrn = VRTIF_Wait:far 
extrn VRTIF_Signal_I:far 
extrn “VRTIF_Signal:far 

3 Network 10 Services 
extrn TX_REAOY:near 
extrn 10_XMIT:near 
extrn 10_Network_Init:near 
extrn J0_ALLOCATE snear 
extrn 10_DEALLOCATE :near 


Vendor Supplied P Semaphore operation 
Vendor Supplied Vv operation/interrupt 
Vendor Supplied V operation 


Transmit ready semaphore 
Start transmission routine 


ao &e 


allucate a buffer 
deallocate a buffer 


include DA_OEF.ASA system definitions 


=e 


cseg segment common 
assume cs:cseg,ds:cseg,es:cseg 
org 600H 


; Initialize -- MO parameters 
Initialize: 


call 10_Network_Init 
retf 


me 
=e 
ee 
se 
ee 
me 
es 
ae 
ae 
=e 
=e 
a 
we 
ee 
= 
“. 
we 
ee 
me 
ee 
we 
ee 
we 
=e 
=e 
me 
ee 
ee 
es 
ae 
=e 
@e 
ee 
ee 
ee 
ae 
we 
=e 
=e 
ee 
ee 
me 
we 
ee 
ae 
we 
se 
we 
ae 
ee 
me 
“. 
ee 
we 
se 
ee 
=e 
we 
ee 
ae 
we 
we 
=e 
ee 
“. 
ae 
we 
me 
we 
ee 
“. 
=e 
se 
ee 
ee 
=e 


ELABORATE START: 

This routine is called by MAIN to elaborate library packages on 
remote processors. After sending the start message to the designated 
processor, this routine suspends the current task (mein) waiting for 
the CONTINUE reply. 


Inputs: TASK_ID (of main) 
Transmit Control pointer (pointer to appropriate start msg) 
Outputs: AX contains the Result code of the elaboration (Zero if OK). 


“τὸ τὸ τὸ ὡς τὸ οὐ τὸ τὸ τὸ πὸ πὸ Ty 
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Remote_Elab Start: 
push = bp 
mov bp, sp 


upon entry to elaborate start, the parameters on the stack 
provide the Transmit Control Ptr necessary to generate the start asg. 


Se ὧν te we 


call 10_Xmit 

push cs 3 vendor Wait needs segment # too 
push (bprOEF_task_id] ᾿ 3 first item in TC8 is semaptore 
call VRTIF_WAIT ; weit for elaboration to complete 


Now elaboration has completed, get result and deallocate receive 
buffer 


-ο te we te 


mov bx, (optOEF_task_id) 

add bx, DEF_TCB_EID 

call REMOVE 

push word ptr (bx+data_field) 
call 10_DEALLOCATE 


get my JCB 

point to entry Q 1 

pull entry of queue (BX ptr) 
fetch completion status 
pointed to by 8X 


Be es te fe οὐ “0 


pop ax get completion status into AX 

pop bp 

retf 
φοοοφοοοφονθδοοσνοοθοφνοοοοοοοφοοσαοθοσοασυσυ δον θοουσδθοοοοοουροοοοοθοοροοφοσοονοφοσοο 
φΦεενφϑενφωδυθϑνοθυ δον δ ϑιυθοϑθθν εν θη ϑοεν ιν εθ δ ϑήθύθεθε θ᾿ 


ELABORATE_WAIT : Suspends a task until it is given the signal 
to continue from the elaborating processor. 


πο τὸ πὸ τὸ 


Go to Sleep on the Semaphore οὐ the calling task. 
INPUTS: 
TASK_ID 
ENTRY_ID 


BB we Be Se Me Se «Ὁ 


emote_Elab_Wait: 
push = bp 
mov bp, sp 


First, check to see if there is already a message waiting on 
the specified entry... 


me Be τὸ te 


mov si, (bp*OEF_Entry) ; 

pushf 3 preserve interrupt status 

eli 3 gO atomic 

test word ptr [si*DEF_Wext_Ptr) ,OFFFFH ; see if anything on entry 


jnz REWO10 3 go on if no wait necessary 
mov word ptr [61,1 ; set WAITING Flag 

push cs 3 vendor P routine needs segment 
push word ptr (bpr0EF_task_id} 

catl VRTIF_WAIT 7 this also reenables interrupts 
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REWO10: 


After resumption, the wakeup message is on the main task’s entry!, 
it will be processed later during the elaborate continue procedure. 


@6 οὖ οὐ νυ 


popf 3 restore interrupt status 


ΠΥ. 
“.9ενδϑιϑϑϑεδηηθθνενϑῦ 488 


ELABORATE CONTINUE : Notifies the elaborating processor that 
the specified elaboration in complete and 
that fit can continue elaboration of otner 
units. 


S Se Se Se te te Oe 


Send “End_Elaborate” message to the processor that allowed 
the elaboration to continue, as determined by the start msg 
still queued to Mains entry! 


Inputs: Task [Ὁ 
ENTRY_IO on entry, changed to transmit control pointer 


: number οὐ parameters : always ZERO 
Remote tlab_Continue: 

push ὃρ 

mov bp, sp 


mov bx, (bpeDEF_Entry] ; fetch entry id 

call REMOVE 3 pull buffer descriptor off entry queue 

mov si, (bx] 3 fetch actual buffer address into οἱ 

mov si, (si+RCP] 3 get receive control pointer from rev buffer 


Now we are done with the received buffer, release it 


ee te te 


call 10_Deallocate ; release buffer, descriptor in BX 

lea ax, (si+OEF_renty_offset] ; fetch reply message pointer 

᾿ῸΝ {bp+DEF_TCP}],ax ; put on stack for XMIT_IO in Transmit control 
call 10_Xmit 3 tramamit message pointed to by 8X 


Remote_Entry 


Send "Request_Entry" message with IN parameters 
Wait on Entry_Wait_Semaphore 

Copy OUT parameters 

Release Buffer 
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PARAMETERS: TASK_ID 
TRANSMIT CONTROL_PTR 
WUM IN PARAMS 
IN_PARAM (offset, segment, length) 


TW_PARAMN (offset, segment, length) 


WOTE: Stack Parameters are removed by caller 


Se Me Be ws τὸ ὦν “ὁ te Ὁὸ 


Remote_Entry: 
push ὃρ 
πον bp, sp 
call 10_Xmit 


Now wait for Accept Complete to wake up 


Se te fe 


push cs 

mov vax, (Op+OEF_task_id] : point to parameters 

push ax 3 offset of semaphore (TCB) 
call VRTIF_Wait 3 go to sleep 

Pop bp 

retf 


=e 
=. 
=e 
= 
ee 
ee 
=e 
= 
=e 
ee 
ee 
=e 
Re 
=e 
we 
Se 
Ss 
Se 
Se 
ae 
ee 
me 
me 
me 
= 
=e 
ee 
=e 
ae 
we 
we 
we 
ee 
=e 
we 
we 
ee 
we 
we 
ee 
ee 
we 
ee 
ee 
ee 
we 
=e 
me 
ee 
“. 
ae 
me 
oe 
= 
ae 
me 
-- 
“. 
=e 
oT 
=. 
we 
se 
se 
oT 
we 
“. 
we 
ae 
oe 
ee 
-- 
“. 
-- 
“. 
=e 


Local_Entry : This routine is called for an entry of a task 

which is local (same processor) as the caller 

Inputs: SRC-TASK_ID 

DST-TASK_IO 

DST-ENTRY_ID 

PARAMTER ADDRESS (OFFSET, SEGMENT) 
Although the task is local to the caller, an 10 buffer is allocated 
to store the necessary pointers required by accepting tasks. This 
is later deallocated as part of the local_end_accept routine. The 
calling task is always suspended, and if the accepting task is “waiting” 
{τ fs signsied to wake up. 


we te ον οὐ τἰ᾽ ον» τ, πὸ τὸ τὸ τὸ τὸ τὸ τὸ 


sre_task_id equ 6 
dst_task_id equ 8 
dst_entry_id equ 10 
entry_peram equ 12 
Local_Entry: 

push = bp 

mov bp, sp 


call 10_Al locate 
mov si, (BX) 


get a buffer descriptor ptr in Bx 
fetch buffer address 


: 
is currently only one parameter is used (either in or out). Take advantage 
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of inis to simplify interface to eccepting task. The adress of the 


data area is provided in the first part of the buffer. 


NOTE: this address 


is backwards (segment= low address, offset=zhigh address). 


mov ex, (bprentry_param) H 

mov (si+2] ,ax 

mov ax, (op+entry_parame2) =; 

mov {si] , ax 

mov [51:4] , bx ; 

mov ax, (bp+sre_task_id] ἢ 

πον (si+DEF_local_task_id] ,ax 

mov si, (bp+dst_entry_id] 7 
ATCAHIC activa follows... Queue entry, 

pushf 

eli 

call INSERT : 

mov 3i , (bprdst_entry_id] 2 

test word ptr (si) ,OFFFFH : 

jz le010 ; 


server is waiting on accept, signal it 


mov si, (bptdst_task_id] ; 
mov word ptr (si+DEF_TCB_EIDI, 
mov 

push cs 

mov ax, (bp+dst_task_id] 

push ax 

call VRTIF_Signal ; 


get offset of peram 


and segment 


stuff buffer descriptor in buffer too 
fetch our task id 

3 ano put in calling task id there 
fetch entry queue head 


if waiting signal acceptor 


place buffer descriptor on entry Q 
fetch entry address again 

see if WAITING 

go on if not 


get task id 


ὃ ; clear (all) waiting flacs 


word ptr (si+DEF_TCB_E!D+DEF_TCB_ENTRY_SI2E],0 ; get other entry 


3 segment of semaphore 


wake up server (may preempt ourselves) 


NOTE: This is the end of the atomic region (above Vendor runtime call 


reenables interrupts! 


(e010: 
ευρέ ; 
push cs Ἧ 
mov ax, (bpesrc_task_id)} 
push ax 
call VRTIF Wait ; 
pop bp 
retf 

; ; 

; Any_Select 


restore interrupt level 
Now try to suspend ourselves 


May not suspend if server is higher 
priority and hes already signaled us! 


Demonstration Project Final Report 


Check to see if any of the entries have caliers. If not, 
set the “Waiting” Flag in each of them, and go to sleep. 
If one entry has 8 queved request, accept it and return 

offset for “Case" table in ΟἹ and Entry pointer in CS:Bx. 


Note that this routine provides the synchronization and buffer 
management functions only. Separate code in the "LINK" 


module is necessary to facilitate parameter transfer. 


Perameter Sequence: 


BP+6 => Τα [Ὁ (Always Current Tesk) 
78 Number of open select alternatives 
Entry_ID #1 
Entry_!ID #n 


PARAMETERS ARE REMOVED FROM STACK BY CALLER 


Output Parameters: 81 - selection entry id 
ES - data segment 
8X - data offset 


me me Be Be οὐ Be τὸ τὸ Me προ Be Be Be Be Be Be Be Me MH πο Be fe 


entry_count equ 8 3 offset from BP for entry count 
entry_list equ 10 ; offset from BP for entry list start 
Any_Select: 

push = bp 

mov bp, sp 


ENTER CRITICAL REGION (cannot allow task to go on an entry queue 
after we have checked it, but before setting waiting flag. 


me τὸ οὐ oe 


pushf 
eli 


3 First check each entry to see if any has a caller... 


Rem_Seld0: 3 will come back here after resume 
mov cx, entry_count (bp) ; tamber of entries 


normaly might want to put OR CX,CX ; JZ raise program_error χὰ 
since ail entries are closed! χὰ 


me τὸ se we 


mov si,0 3 entry index 
Rem_Set 10: 
mov di,entry_list (bp+si} 3 get next entry 1D 
test word ptr (di+DEF_Next_Ptr] ,OFFFFH ; see if δὴ cailer is queued 
jnz Rem_Sel50 3 {f caller is present, go select 
add si,2 3 go to next entry fn list 
loop Rem_Sett0 
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- 


all of the Entry Queues are Empty, mark each Waiting flag 
and go to sleep. 


mov 
mov 


Rem_Sel30: 


Rem 


WP we te te te oe 


mov 
mov 
add 
loop 


3i,0 
cx, entry_count [bp] 


di,entry_list (bp+si)} 
word ptr (di],1 

si,2 

Rem_Set30 


reset pointer 
fetch number of entries again 


fetch entry id 
set WAITING flag 
goto next entry 


The following runtime call will suspend this task, when it 
resumes, the interrupt flag will be set again, and presumably, 
one of the entries will have a caller queued. 


push 
push 
call 


cs 


[bpepeF_task_id} 


VRTIF_Wait 


Now clear all the waiting flags 


eli 
ον 
mov 


Set40: 


3i,0 

cx, (kerentry_count] 
di,entry_list (bpesi) 
word ptr (di) ,0 
Rem_Sel40 


Rem_Set00 


=e te πὸ 


we fe 


=e 


push segment of wait_semaphore 
push offset of wait_semaphore taskid 
do wait on semaphore 


reset pointer 
fetch number of entries again 


entry list on stack 
clear waiting flag 


go back and find caller 


There is a caller on this entry queue, do start accept 
Fetch the Caller’s buffer, which has a (backward) pointer to 
the parameter data 


em Sal50: 

mov di, (di+DEF_Next_Ptr) 3 get buffer descriptor 

mov bx, [di] 3 fetch buffer address 

mov ax,si 3 get selector into AX 

shr ax,1 3 get count 

ine ax 3 to be compatible with VRTIF 

popf 3 restore interrupt status 

pop bp 

retf 3; Parameters are removed by caller 
rEPESERESEIE ESSE SELIOSASES SSE T SSIES E RIERA AEI EAA IIIREE IIR TEL IEA 


Remote Accept (TASK_ID, ENTRY_ID) return ES:BX_Peram_Pointer 
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Simple Accept, see if someone on entry queue, if so 
return with pointer to buffer in ES:8x, otherwise set 
“Waiting Flag and go to sleep on semaphore. 

Inputs: ΤΑΙΚ 10, ENTRY_ID 


Outputs: Returns ES:8X pointing to Parameter Data List 


Remote_Accept: 
push bp 
mov bp, sp 


me τὸ te 


mov si, (op+OEF_Entry] 3 fetch address of entry ἃ 


pushf 3 save interrupt status 

eli 3 go atomic 

test word ptr [si+DEF_WEXT_PTR] ,OFFFFH ; if Zero, then list is empty 
jnz Ra010 ; if caller is there, take it! 


No caller on entry queue. Set waiting flag and go to sleep 


mov word ptr (si],1 ; set flag 

push cs 3 push segment of my task semaphore 
mov ax, (optDEF_task_id) ; get address of TCB 

push ax ᾿ 

call VRTIF_WAIT 3 90 to sleep waiting for caller 


NOTE after vendor runtime call - interrupts are enabled! 


Now Something is on the queue, provide address of data area in 
ES:BX and return to caller. 


RAO10: 
popf 3 restore interrupt status 
mov si, (bp+DEF_Entry]l; get entry address again 
mov si, (si+DEF_NEXT_PTR) ; get address of buffer descriptor 
mov bx, (si 3 fetch actual buffer eddress 
mov ax,cs 3 provide caller with segment of data 
mov es , ax 
mov (bx) , ax 3 put deta address as first words in buffer 
tea ax, [bx+data_field) ; but written backwards 
mov (bx+2) , ax 
pop bp 
retf 
ΣΧ ΧΕ ΣΥΥΧΥΧΥΧΧΧΥΣΥΧΥΣΣΧΧΧΧΧΧΧΧΧΧΧΥΧΧΥΣΧΧΧΧΧΧΧΧΧΖΧΖΙΙΙ) 
Remote_End_Accept 


we he Fe ee ee te 


Send output perameters to caller. 
Release buffer used to hold input (and output for now) parameters. 


Remote_End_Accept: 
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push = bp 
δον bp, sp 


mov bx, (bp+OEF_Entry) 

call REMOVE 

push bx 

mov si, (bx) 

mov si, (sf+RCP} 

tsa ax, (3i+DEF_reply_offset) 
mov (bp+DEF_TCP) , ax 

call 1O_Xmit 


fetch entry queve pointer 

pull it off queue, leaving BX = BUFPTR 
save buffer descriptor pointer 

fetch actual buffer address into SI 
get RCP from rev buffer 

fetch reply message pointer 

replace ENTRY on stack with TCP 
transmit reply 


Be Me τὸ πὸ τὸ Be ἂν te 


Now we are done with the received buffer, release it 


we Me se 


pop bx 3 get descriptor ptr back 
call 10_Deallocate ; retease buffer, descriptor in ΒΧ 
pop bp 
retf ΄ 
ΥΣΣΣΣΧΥΥΣΥΣΥΣΥΣΥΧΥΥΥΣΥΥΣΥΥΥΣΥΣΣΥΥΥΥΧΥΣΥΥΧΥΧΥΥΥΣΥΥΣΣΧΥΣΣΥΥΧΥΣΥΧΥΧΧΙΙΙ) 
Local_End_Accept 


Allow caller to continue (Note: this is for entry calls with parameters 
that are all passed by reference. No = .py-back is required). 

All entries whether remote or 'ocal use a buffer, therefore deal locate 
it when complete. 


Re Me we Be Me ee τὸ τὸ 


Local_End_Accept: 
push = bp 
‘mov bp, sp 


mov bx, (Op+OEF_local_entry_id] ; fetch entry ID 


call REMOVE 3 pull entry off queue BX now 3 buffer 
mov si, (oxi 3 get buffer address 
push cs 3 push segment of semaphore 


push word ptr [(si+DEF_local_task_id] ; push calling Task’s ID 
call 10_Deal locate 3 deallocate buffer 2 BX 
call VRTIF_ Signal 3 signal task to continue 


pop bp 


This routine is called by the interrupt handler (in 
the 10 Module) to initiate action besed on the 
receipt of a packet. When the service handler is 
called, BX contains the eddress of the buffer 


πὸ Be πὸ τὸ πὸ πὸ te 
ee Be “ὁ οὐ Me te "ὁ 


ὃ 
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mov si, (bx) 3 get address of δεϊωδὶ buffer 
mov si, [si+RCP) Σ Receive control pointer 

mov di, (si+DEF_cmd_offset) 3 fetch command 

and di, vector_mask ; mask for valid vector values 
jmp vector [di] 


The following vector table implements the ‘case’ statement 
on the message ACTION Field 


we Me me te 


vector_mask equ 000001108 = ;:_-valid range 0 - 6 
vector label word 

offset Begin_Elaborate 

offset End_Elaborate 

offset Request_Entry 

pffset Accept_Complete 


222? 


3; Future versions of the vector table wilt include 

: Begin_Remove_Entry 

; End_Remove_Entry 

7 Begin_Abort 

5 End_Abort 

; Begin_Terminate 

: End_Terminate 

Σ Shared_Variable Request 

5 etc. 
CEREUEVEREEUSESALERETELE REET AREA ERERI EET TATETATLESRER TET LE ATRL 


RESEEEUEPILEREEUSELUUEE TER EEAETRER TEETER AERE LTTE TR TEESE APE 
; This code section is executed upon receipt of a message initiating 
; & Begin_Elaborate request. 8X points to buffer descriptor. 
Begin_Elaborate: 
mov di, [bx) 3 get data buffer 
mov di, (di+rcP) 3 fetch receive control pointer 
mov $i, (di+DEF_eid_offset} ; get entry [Ὁ 
call INSERT 3 put buffer on entry queue 
push cs 3 semaphore segment 
push (di+OEF_tid_offset) 3 push task id of destination 
call VRTIF_Signal_! 3 signel task to continue 
ret 
PPETTEPESIIS ISIS TTIITEASI TELE 11} 211} 212 2121 22 2222} 81} 
e 
3 This code section is executed upon receipt of ὁ message initiating 
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΄ 


an End_Elaborate. This message implies that the specified elaboration has 
been completed on the remote processor aid elaboration can continue 
on the primary processor. 


INPUTS: BX points to buffer descriptor. 


me τὸ το ὧν οὐ “Ὁ 


End_Elaborate: 
mov si, (bx) ; get buffer address 
mov si, (si+RCP] 3 fetch receive control pointer 
push es 3 semaphore Segment 
mov ax, [si+DEF_tid_offset]) ; semaphore Offset 
push ax 
mov si, (si+DEF_eid_ offset) get entry id offset 
mov word ptr {si} ,0 clear WAITING FLAG 


call Insert 
call VRTIF_Signal_!I 


put on caller’s queue 
signal task to continue 


ee we we we 


= 
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=e 
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This code section fs executed upon receipt of a message initiating 
an entry call 


Place Suffer οὔ Entry queue, If “Waiting” for that entry is [RUE, 
ion clear all Yaiting Flags and signal Wait Semaphore. 
INPUTS: 
8x 3 Buffer descriptor pointer 
SIs Receive control pointer (RCP) 


“κι ee eS a eT er ee 2 


Request_Entry: 
mov ax, (si+DEF_tid_offset) 
mov si, (si+DEF_eid_offset) 
mov di, [8x} 


save task id for later 
fetch entry id for later 
fetch buffer address (again) 


Re te Me 


currently only one parameter is used (either in or out). Take advantage 
of this to simplify interface to accepting task. The address of the 

data srea is provided in the first part of the buffer. NOTE: this address 
is backwards (segmentzlow address, offsetzhigh address). 


Be Be Se Be πὸ te 


les ax, (di+data_fieid) 3 get offset of parameter 

mov (di+2],ax 

mov ax,cs ; and segment 

mov (di) ,ax 

mov [4144] , bx 3 stuff buffer descriptor in buffer too 


ATOMIC action follows... Queue entry, if waiting signal acceptor 


me Se οὐ 


pusht 
elf 
mov cx, (811 Σ get WAITING fleg for this entry 
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place buffer descriptor on entry 9 
test weiting flag 
go on if not 


call INSERT 
or cx, ex 
jz redid 


server is waiting on accept, signal it 


mov οἷ, ἀχ Σ get task id 
mov word ptr (si*DEF _TCB_EID],0 ; clear Call) waiting flags 
mov word ptr (si+OEF_TCB_EID+OEF_TCB_ENTRY_SIZE),0 ; get other entry 


push cs 3 segment of semsphore 
push si 3 offset of semaphore (first in TCB) 
VRTIF _Signal_t 3 wake up server 


restore interrupt level 
return to interrupt handter 


This code section is executed upon receipt of a message completing 
an accept body (end rendezvous) 


Post buffer containing Out Parameters and signal task to wake up 
INPUTS: 


BX = Buffer descriptor pointer 
SI = Receive control pointer (RCP) 


Me te Be Be τὸ ὦν Be τὸ τὸ το τὸ te 


Accept_Complete: 
mov si, (si+DEF_tid_offset] ; fetch task id of caller 
mov (si*DEF_TCB_REPLY},bx ; provide caller with reply buffer 
push cs 3 push segment of caller semaphore 
e 
[ 


push si push offset of same (TCB) 
call VRTIF_Signal_} wake up caller 
to finish interrupt 


PETRI UIUEPRURELATEUE TIRE EIELALEA EAA EELIERALALI TAIT LIEE 
; ; 
3 REMOVE - Remove Entry that is on entry queve δ 
Η ἢ 
3: Inputs: BX points to entry a 3 
; Output: ΒΧ points to buffer descriptor that was dequeued ; 
ἬΝ ; 
; All other registers are preserved 3 
; : 
ΠΥΧΧΥΣΧΣΧΧΥΥΧΧΙΧΧΧΣΣΧΧΣΣΧΧΧΧΧΧΧ ΧΙ ΣΧ ΖΖΖΖΖΖΖΣΖΖΣΖΣΖΩΣ 
REMOVE : 


Η: 
5.8 
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; do list operation as atomic action 
: 

pushf 

cli 


mov si, (BX+DEF_NEXT_PTR] 3 fetch buffer descriptor 
mov ax, (si+DEF_NEXT_PTR) ; get next buffer 
mov (BX+DEF_NEXT_PTR] , ax 3 update queue head 
popf 
mov bx,si g return pointer in BX 
pop si 
pop ax 
ret 
PEST EERE SEOSORSAEESLISER SAT ER SEPARA SEER ESAEERAISEEETISERAAEREA EERE 


INSERT - INSERT Entry onto the end of an entry queue 


Inputs: SI ppints to entry a 
BX points to buffer descriptor 


Outputs: 51 points to last entry on ὦ 


Alt other registers are preserved 


eS eT ee SS ee en ed 
me ae Be Be τὸ Ne Be fe we Me Be fe 


ΧΕ IRAP SER ETAT ORES STEELE REER ETRE EREERIREREE SIE RSER ERAT EL 
NSERT: 
pun ax 
; do list operation as atomic action 
pushf 
cli 
INSERT10: 
mov ax, (si+0EF_next_ptr] 3 get next buffer on entry queve 
or ax, ax 3 see if end of list 
jz INSERT20 7 end of list, go insert it 
; this is not end of list, keep searching 
mov si,ax 
jmp’ INSERT10 
‘ 
¢ found spot on list, insert it 
INSERT20: 
mov (s{+DEF_next_ptr] , bx ¢ put on end of List 
popt 3 restore interrupt flag 
mov bx, si 3 return pointer in BX 
pop ax 
ret 
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pege 55,132 
TITLE Setup - Distributed Ada Network Initialization 
PPPPePETTeeereeer eer iter ere est t ee eeeee ee eee iii eireee eee eee 
; FILE: DA_SETUP.ASM : 
; Distributed Ada - Setup ; 
, e 
; This module initilizes the network to prepare for distributed : 
; processing. H 
; : 
; ; Distribution and Copyright ΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣΣ Te 


δὴ 1 1} 2211} 

Derivation : ἰδότεκ Distributed Ada V1.0 
This Distributed Ada Runtime inherits the lLabTek copyright. 
The following copyright must be included in all software 
utilizing this Ada Runtime. 


[2 

¢ 
Copyright 1989 by LabTek Corporation, Woodbridge, CT, USA : 
Permission to use, copy, modify, and distribute this ; 
software and its documentation for any purpose and without : 
fee is hereby granted, provided that the above copyright Ἢ 
notice appear in all copies and that both that copyright : 
notice and this permission notice eppear in supporting : 
docurantation, and that the name of LabTek mot be used in ἃ 
δόνοι εἰ αἰ πα or pdlicity pertaining τὸ distribution of the δ 
software without specific, written prior permission. ; 
LabTek makes no representations about the suitability of ; 
this software for any purpose. Iz is provided “as is® 2 
without express or implied warranty. ; 
, 

᾽ 

: 

¢ 

¢ 

Η 

͵ 


ΣΣΣΣΣΣΣΣΣΣΣΣΣ1111 Disclaimer ΣΣΣΣΣΣΣΣΣΣ111}21}1}11} aaa aaa eas 


This software and its documentation are provided "AS IS" and 
without any expressed or implied warranties whatsoever. 

No warranties as to performance, merchantability, or fitness 
for a perticular purpose exist. 


In no event shall any person or organization of people be 
held responsible for any direct, {ndirect, consequential 
or inconsequential damages or lost profits. 


ee τὸ τὸ οὐ τῷ τῷὸ ὧὐ SP ὁ τὸ τὸ τὸ CT Te hd πο al πὸ 


include DA_NW.ASM 


cseg segment common 
essume c8:cseg,ds:cseg,es:cseg 
org OAddH 

Setup: 
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mov dx,cntrl 3 Gate array controller 
mov al,eth_enable_ reset a 
out dx,al 
mov al,eth_ disable reset 
out dx,al 
mov al,eth_access_prom 
out dx,al 
mov οχ,ό 
πὸν = 8X, CS 
mov eS, ax 3 set es:di to receive board 
mov di,offset BOARD_ADDRESS ; address from prom 
mov dx,prom_address_0 
GET_ADDRESS: 
in al ,dx 
stosb 
ine ἀχ 


loop GET_ADDRESS 


5 mov dx,cntrt 3 select no-sharing adapter, 
mov al,eth_recv_select ; and external transceiver 
out dx,al 
mov dx,gacfr ; 8K of memory mapped space, 
mov at,eth_len_config ; with interrupts enabled 
out dx,al , 
mov dx,dqtr 3 # of bytes to transfer on 
mov al,eth_rem_DMA_burst 3 @ remote OMA burst (n/a) 
out = dx,al 
mov dx,idefr 3 interrupt IRQ and DMA 
mov ai,eth_irq_line 3 channel selection (DMA n/a) 
out dx,at 


dx, damsb 
al,eth_rem_DMA_config 


mov δι. configuration for remote 
mov 

out dx,al 

mov 

mov 

out 


OMA. Not used, but minimum 
value needed 


start of receive buffer. 
Value MUST match that in 
NIC_pstart 


a&,petr 
al,eth_recv_buf_start 
d&,al 


mov 8 6dx, pspr 3 end of receive buffer, 
mov = al,eth_recv_buf_end 3 Value MUST match thet in 
out = dx, all 3 NIC_petop 

mov dx, NIC_er 3 Stop WIC activity 

mov = al,eth_nic_stop 

ouz = dx, al 

mov dx, NIC_der 3 local OMA transfers as 
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al,eth_nic_OMA_config 
dx,al 


dx, ,NIC_rberd 
al,eth_remote_DMA_lo 
dx, al 


dx ,NIC_rber1 
al,eth_remote_DMA_hi 
dx, al 


Ox NIC γον 


al,eth_packet_types 
d&,al 


dx, NIC_ter 
al,eth_nic_mode 
dx, al 


ἄχ, ΝΠ bry 
al,eth_bndy_start 
dx,al 


dx , NIC _pstart 
al ,eth_recv_buf_start 
dk,al 


dx, NIC_pstop 
al,eth_recv_buf_end 
cx, al 


dx, ,NIC_isr 
al,eth_int_status 
dx, al 


cx, NIC_ime 
al,eth_ints_enabled 
dx,al 


dx, NIC_er 
al,eth_access_pege_1 
dx,al 


a, phys_eddress_0 
ax,cs 
ds, ax 


8i,offset BOARD_ADDRESS 


cx,6 


we Me te 


ee 


me te fe 


΄ 


8 byte bursts 


remote DMA setup (remote 
DMA not used, only local 
used) 


hi byte of # of bytes to 
transfer during a remote 
OMA operation 

eccept runt, errored, broad- 


cast and multicast packets 


go into internal loopback 
mode to fini.h programming 
(see anomalies - p. 52) 

overwrite protection rgtr. 


(protects unread packets) 


start of receive queue 


end of receive queue 


clear interrupt status 


enable interrupts 
tronsmit interrupts are 
at bit 02h 


access page 1 registers 


3; let NIC know its address 


from the prom 
number of addresses to give 


FILL: 


BOARD_ADORESS 


eseg 
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inc dx 

loop GIVE_ADDRESS 

mov dx, NIC_curr 

mov al,eth_recv_buf_start 
out dx,al 


mov dx, NIC_er 
mov al, eth_access_page_0 
out dx,al 


mov dx,NICLcr 
mov al,eth_start_nic 
out dx,al 


mov dx, NIC ter 
mov al,eth_exit_mode 
out dx,al 


mov ax, net_memory_seg 
mov 685,8Χ 

mov Cx, Net_memory_size/2 
χοῦ di,di 


mov ax,0000 


FILL 


db 6 dup (3) 


ENO 


ee we ων τι 


me fe “ὁ "» 


ae 


toed all addresses 


load current receive pointer 
with petart 


access page 0 registers 


start NIC chip 


exit internal loopbeck mode 


initielize LAN memory to 
zeroes 

in words 

start at begin of segment 


initialization vatue 


holds board address 
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page 55,132 
OPPS P TEE TEETEEIOTOLESTAT EP IEREETI ELITE IELTS EREE ERATE 
; FILE: OA_VRTIF 
; Distributed Ada - Vendor Runtime Interface 
; This module provides the addresses within the 
; Vendor supplied runtime for required tasking primatives. 
partcarasasaararazzas Oistribution and Copyright Σ::7:7:: 72:2 11 11}111 
3 Derivation : LabTek Distributed Ada v1.0 
3 = This Distributed Ada Runtime inherits the LabTek copyright. 
; The following copyright must be included in all software 
: utilizing this Ada Runtime. 
3 Copyright 1989 by LabYek Corporation, Woodbridge, CT, USA 
Σ Permission to use, copy, modify, and distribute this 


; software and its documentation for any purpose and without 
; fee is hereby granted, provided that the above copyright 

3; Notice appear in all copies and that both that copyright 

; notice and this permission notice appear in supporting 

3; documentation, and that the name of LabTek not be used in 
3; advertising or publicity pertaining to distribution of the 
; software without specific, written prior permission. 

3 LabTex makes no representations about the suitapility of 

3 «this softyare for amy purpose. It is orovicded “as is 

; without express or implied warranty. : 


ae eeeerereeeresece ἡ 7 οοωνυοοοοοοοοοοοοοονοο τ οοφοφδοδοφρφοοοθθοο 
ee ee ee ee Disclaimer φΦφφνειφϑθϑεθϑθνονθονϑενθϑ  ϑυδιεεηθνοθεσεν 


or 


This software and its documentation are provided “AS 15" and 
without any expressed or implied warranties whatsoever. 

No warranties as to performance, merchantability, or fitness 
for a particular purpose exist. 


eS eT τὸ “0 


In no event shall any person or organization of people be 
held responsiole for any direct, indirect, consequential 
or inconsequential damages or lost profits. 


we 
we eo “ὁ οὐ οὐ Be ον το τὸ Be Me τὸ Me Me ὅν Be Ne Me Be te te το πο ν Be Ne Me πὸ Be τὸ ὁ Bs πὸ πὸ Me Me Me we Me 


Be Se Be Be Ne 


public VRTIF_18259, VRTIF_vector_base 
public VRTIF_Wait, VRTIF_Signal, VRTIF_Signal_! 


address of interrupt controller chip 
base of vector table 


VRTIF_ 18259 equ 20H 
VRTIF_vector_base equ 200H 


we te 


vetif segment δὲ 4000h 
org 3FS6H 
VRTIF_ Wait label far 3 RITESS7P P semaphore operation (non- interrupt) 
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VRTIF_Signal 


VRTIF_Signal_I 


vetif 


3F6CH 
far 


3F21H 
far 


Demonstration Project Final Report 
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; RITESS?V V semaphore operation (non- interrupt) 


; RITESI2VI V semaphore operation (interrupt) 
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21 Appendix J - Key Control for the Border Defense System 
Version 1.0 
21.1 Purpose 


This document describes the technique and procedures for loading and verifying encryption 
keys used by the Border Defense System (BDS). 


21.2 References 


Data Encryption Standard, U.S. Pee of Commerce, National Bureau of Standards, 
FIPS publication 46, 1977 January 15. 


21.3 Key Management 


Encryption keys used with the BDS shall conform to the Data Encryption Standard (DES) 
format. These keys consist of a bit string of 56 binary digits. Keys shall be entered as 7 pairs 
of hexadecimal digits, each pair representing 8 bits of the string. A minimum of 1 space 
shall be entered between each pair. The pairs of digits shall be terminated by an ASCII 
carriage return. No other characters other than space, δε δὲ τον return, digits 0 through 9 
and letters A chrough Z (case insensitive) are permitted. Note that parity bits are not 
entered into the BDS (or related hardware) by users, but may be computed internally within 
the system to augment the 56 bit string. Keys shall be provided by the security officer prior 
to system initialization. 


Key entry shall oc via an ASCII keyboard interface in either upper or lower cave charactors. 
Keys shall be entered twice to verify that there are no errors Garin entry. Keyboard echo 
shall be disabled during key entry. BDS equipment shall verify keys are in the correct 
formnat and ensure that both key entries are identical. 

Each BDS system component requiring a key, shall not become fully operational until after 
a conforming key has been entered. Key entry shall be accompanied by the following 
messages, as appropriate: 


Prompt 1: 
ENTER ENCRYPTION KEY : 


Prompt 2: (only if Key entry 1 {s valid) 
REENTER ENCRYPTION KEY: 
Response to valid entries: 
KEY ACCEPTED 
Response to invalid entries: 
KEY REJECTED, INVALID FORMAT 


or 
KEY REJECTED, VERIFICATION ERROR 
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